Re: Question with hashed IN

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Question with hashed IN
Дата
Msg-id 11768.1061135643@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Question with hashed IN  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Ответы Re: Question with hashed IN  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: Question with hashed IN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Sun, 17 Aug 2003, Tom Lane wrote:
>> That doesn't make any sense to me --- AFAICS, only the planner pays any
>> attention to reltuples, so it could only affect things via changing the
>> plan.  Could we see details?

> I've included a perl file that generates data like that I was using and
> the output of the commands from that through psql -E on my machine.  The
> times seem pretty repeatable in any order so caching and such doesn't seem
> to be playing a big part.

Oh, I see what it is.  The initial sizing of the hash table (number of
buckets) is done using the planner's estimate of the number of rows out
of the subplan.  In your later examples, the hash table is woefully
overloaded and so searching it takes longer (too many items on each
hash chain).

I'm not sure how important this is to work on.  We could try to make the
executor's hash code more able to adapt when the hash table grows beyond
what it was expecting (by rehashing, etc) but personally I'd rather spend
the time on trying to improve the estimate to begin with.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: compile error on cvs tip
Следующее
От: ivan
Дата:
Сообщение: DOMAIN NEED CAST ?