Re: [SQL] bad select performance fixed by forbidding hash joins - Mailing list pgsql-sql

From Tom Lane
Subject Re: [SQL] bad select performance fixed by forbidding hash joins
Date
Msg-id 2107.932577609@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SQL] bad select performance fixed by forbidding hash joins  (George Young <gry@ll.mit.edu>)
Responses Re: [GENERAL] Re: [SQL] bad select performance fixed by forbidding hash joins
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] inheritance
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Re: [SQL] bad select performance fixed by forbidding hash joins