Re: Further pg_upgrade analysis for many tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Further pg_upgrade analysis for many tables
Дата
Msg-id 23231.1353015939@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Further pg_upgrade analysis for many tables  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Could we use some adaptive mechanism here?  Say we use a list for the
>> first ten entries, and if an eleventh one comes in, we create a hash
>> table for that one and all subsequent ones.  All future calls would
>> have to examine both the list for the first few and then the hash table.

> Is it necessary to do so? Do we know for sure that a 10 elements hash
> table is slower than a 10 elements list when only doing key based
> lookups, for the object data type we're interested into here?

Well, we'd want to do some testing to choose the cutover point.
Personally I'd bet on that point being quite a bit higher than ten,
for the case that sequence.c is using where the key being compared is
just an OID.  You can compare a lot of OIDs in the time it takes
dynahash.c to do something.

(I think the above sketch is wrong in detail, btw.  What we should do
once we decide to create a hash table is move all the existing entries
into the hash table, not continue to scan a list for them.  There's a
similar case in the planner for tracking join RelOptInfos.)
        regards, tom lane



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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Hash id in pg_stat_statements
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: add -Wlogical-op to standard compiler options?