Re: [HACKERS] Hashjoin status report

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Hashjoin status report
Дата
Msg-id 10226.926024607@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Hashjoin status report  (The Hermit Hacker <scrappy@hub.org>)
Ответы Re: [HACKERS] Hashjoin status report  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] Hashjoin status report  (The Hermit Hacker <scrappy@hub.org>)
Re: [HACKERS] Hashjoin status report  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Re: [HACKERS] Hashjoin status report  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
>> Opinions?  Should I plow ahead, or leave this to fix after 6.5 release?

> Estimate of time involved to fix this?  vs likelihood of someone
> triggering the bug in production?

I could probably get the coding done this weekend, unless something else
comes up to distract me.  It's the question of how much testing it'd
receive before release that worries me...

As for the likelihood, that's hard to say.  It's very easy to trigger
the bug as a test case.  (Arrange for a hashjoin where the inner table
has a lot of identical rows, or at least many sets of more-than-10-
rows-with-the-same-value-in-the-field-being-hashed-on.)  In real life
you'd like to think that that's pretty improbable.

What started this go-round was Contzen's report of seeing the
"hash table out of memory. Use -B parameter to increase buffers"
message in what was evidently a real-life scenario.  So it can happen.
Do you recall having seen many complaints about that error before?
        regards, tom lane


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

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Hashjoin status report
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Hashjoin status report