Re: WIP: extensible enums
От | Tom Lane |
---|---|
Тема | Re: WIP: extensible enums |
Дата | |
Msg-id | 14145.1287347160@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: extensible enums (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > On 10/17/2010 01:20 PM, Tom Lane wrote: >> The way I'd be inclined to design this is that altering an enum doesn't >> change its pg_type entry at all, just add another row to pg_enum. >> When first needing to compare values of an enum, load up the typcache >> entry for it. > Perhaps mistakenly I wanted to avoid doing that as it would slow down a > retail comparison quite a lot, especially in the case of an enum with a > very large label set. That's why I put the sorted property and label > count in pg_type. Just going back to this point: I don't buy that argument at all. If you have to consult pg_type to find out whether fast or slow comparison is needed, you've already burned all the cycles required for a cache lookup. The only way that a large typcache entry would really be a performance issue compared to just consulting pg_type is if it had to be refreshed a lot, which doesn't seem like a likely problem. regards, tom lane
В списке pgsql-hackers по дате отправления: