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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: George Young <gry(at)ll(dot)mit(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: [SQL] bad select performance fixed by forbidding hash joins
Date: 1999-07-21 17:20:09
Message-ID: 2107.932577609@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-sql

George Young <gry(at)ll(dot)mit(dot)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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Hub.Org News Admin 1999-07-21 17:50:50
Previous Message Guy Fraser 1999-07-21 17:08:26 How can I do an UPDATE OR CREATE ?

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 1999-07-21 17:57:35 Re: [GENERAL] Re: [SQL] bad select performance fixed by forbidding hash joins
Previous Message Hannu Krosing 1999-07-21 16:26:00 Re: [HACKERS] inheritance