Any note on performance implications? type-id vs. text

[talksik]

Thank you for this!

I was just curious whether I should just go with having the primary key as text or use the scripts to have a type_id in SQL? The text approach seems simpler, but wondering how it impacts Postgresql performance.

Also, the docs in the #Usage section put the type of the "id" field as user_id. Is it supposed to be type_id? Is that a typo?

[loreto]

I know this response is coming a year later, but I didn't really have a good perspective on this question before.

Now that we've been using typeid in production in our own postgres here are my thoughts:

• Technically, there is a performance hit with using string vs, say, uuid as the underlying type for storying typeids.
• However, at our scale, we found that using the text approach is better because the usability and integration with existing tools is much more better.
• I therefore recommend the text approach unless you're dealing with a case where you know performance is paramount. But it will be more painful.
• If performance is paramount, then I think one might be better served by using the native postgres extension anyways. Not only does it move all the parsing and checking to native code, but maybe more importantly, it makes typeid feel like a native type which also a win on the ergonomics.
• That said, to use the extension you need to be in an environment where you have the rights to install it (for example, some managed postgres instances might not allow you to do that unless you convince the provider of the managed db to include it as a supported extension)