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
|
Список | 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 по дате отправления: