Re: [SQL] bad select performance fixed by forbidding hash joins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [SQL] bad select performance fixed by forbidding hash joins
Дата
Msg-id 2107.932577609@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [SQL] bad select performance fixed by forbidding hash joins  (George Young <gry@ll.mit.edu>)
Ответы Re: [GENERAL] Re: [SQL] bad select performance fixed by forbidding hash joins  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-sql
George Young <gry@ll.mit.edu> writes:
> Yes!  PGOPTIONS="-fh" made the query time go from 16 seconds to 2 seconds!
> Is this a safe thing to leave on permanently, or is there some way to set
> PGOPTIONS for just this query?

I wouldn't recommend leaving it on as a long-term solution, because
you're hobbling the system for cases where hashjoin *is* the best
method.  AFAIK there is not a SET VARIABLE method for enabling/disabling
plan types on-the-fly, though perhaps one should be added.

The right long-term solution is to figure out why the system is
misestimating the relative costs of the two plans, and fix the cost
estimates.  (The system is estimating that the mergejoin is about 4x
slower than hash; if it's really 8x faster, there is something pretty
broken about the estimate...)

I am interested in looking into this.  If your data is not proprietary,
perhaps you would be willing to send me a database dump so that I can
reproduce the problem exactly?  (If the dump is no more than a few
megabytes, emailing it should be OK.)  No big hurry, since I probably
won't be able to get to it for a week or so anyway.

            regards, tom lane

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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] inheritance
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] Re: [SQL] bad select performance fixed by forbidding hash joins