On 1 wrz 2013, at 05:10, Vitalii Tymchyshyn <tiv...@gmail.com> wrote: > > > Well, there are some more options: > a) Store int keys and do mapping in the application (e.g. with java enums). > This can save you a join, that is especially useful if you are going to do > paged output with limit/offset scenario. Optimizer sometimes produce > suboptimal plans for join in offset/limit queries. > b) Store small varchar values as keys (up to "char" type if you really want > to save space) and do user display mapping in application. It's different > from (a) since it's harder to mess with the mapping and values are still more > or less readable with simple select. But it can be less efficient than (a). > c) Do mixed approach with mapping table, loaded on start into application > memory. This would be an optimization in case you get into optimizer troubles. > > Best regards, Vitalii Tymchyshyn
I'd like to leave database in readable form because before I add some new queries and rest endpoints to the application, I test them as ad-hoc queries using command line. So variant a) isn't good for me. Variant b) is worth trying and c) is easy to code, but I still prefer having all this data in database independent of application logic. Thanks for suggestion, Lukasz -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
