Re: extensible enum types

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: extensible enum types
Дата
Msg-id 12725.1277132465@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: extensible enum types  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: extensible enum types  (Andrew Dunstan <andrew@dunslane.net>)
Re: extensible enum types  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Well, having to do a cache lookup already makes it a couple orders of
>> magnitude more expensive than an OID comparison.  However, it's hard to
>> say how much that matters in terms of total application performance.
>> We really could do with a bit of performance testing here ...

> I have done some. The performance hit is fairly horrible. Adding cache 
> lookups for the enum rows to the comarison routines made a REINDEX on a 
> 1m row table where the index is on an enum column (the enum has 500 
> randomly ordered labels) jump from around 10s to around 70s.

Hmmm... that's bad, but I bet it's still less than the cost of comparing
NUMERICs.  Also, did you make any attempt to avoid repetitive cache
lookups by storing a pointer in fn_extra (cf array comparisons)?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch: psql \whoami option
Следующее
От: Robert Haas
Дата:
Сообщение: deprecating =>, take two