Cast value to text to make filter work with uuid primary key columns

[vesterbaek]

Check for uuid primary key and add typecast if required to support join between model and watson tables

[etianen]

Interesting. I wonder if we couldn't make it more generic by casting {table_name}.{pk_name} to string if it's not an integer primary key. That would presumably account more more fields than a UUID.

[vesterbaek]

Yup, I actually did that in my first implementation. The title of this pull request is a hint about that :). I added explicit support for the uuid type for performance reasons. We could add a fallback to text cast after the uuid check

[etianen]

How does the uuid conversion improve performance over the string
conversion? I'd have thought that both blow the use of indices out of the
water.

On Wed, 2 Mar 2016 at 14:36 Jeppe Vesterbæk notifications@github.com
wrote:

Yup, I actually did that in my first implementation. The title of this
pull request is a hint about that :). I added explicit support for the uuid
type for performance reasons. We could add a fallback to text cast after
the uuid check

—
Reply to this email directly or view it on GitHub
#154 (comment)
.

[vesterbaek]

uuid is a native type with 128 bit length: http://www.postgresql.org/docs/9.1/static/datatype-uuid.html. Representing the uuid as text leads takes more storage (see eg. http://stackoverflow.com/questions/33836749/postgresql-using-uuid-vs-text-as-primary-key). In this case where one table has text and one has uuid, my knowledge of PostgreSQL is not good enough and I'm not sure if there is a performance gain by casting to uuid.

If we added a object_id_uuid column to watson_searchentry (like you have for int) we would get improvements in both required storage space and in performance.

[etianen]

I think it's the sort of thing that could only be shown using benchmarks. I
suspect, however, that any performance difference would be negligible,
since the database won't be able to use indices either way. What's certain,
however, is that the code required for the "cast to string" approach is
much smaller, which is a definite win!

On Wed, 2 Mar 2016 at 21:46 Jeppe Vesterbæk notifications@github.com
wrote:

uuid is a native type with 128 bit length:
http://www.postgresql.org/docs/9.1/static/datatype-uuid.html.
Representing the uuid as text leads takes more storage (see eg.
http://stackoverflow.com/questions/33836749/postgresql-using-uuid-vs-text-as-primary-key).
In this case where one table has text and one has uuid, my knowledge of
PostgreSQL is not good enough and I'm not sure if there is a performance
gain by casting to uuid.

—
Reply to this email directly or view it on GitHub
#154 (comment)
.

[vesterbaek]

Closing this one on favor of #169