Re: add_path optimization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: add_path optimization
Date
Msg-id 4925.1233772727@sss.pgh.pa.us
Whole thread Raw
In response to Re: add_path optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: add_path optimization
List pgsql-hackers
I wrote:
> Now, since I'm running without any stats, it might be that it's
> estimating similar costs for the one-key and two-key merges; but I don't
> see why that would happen for you.  Off to do some debugging.

... well, actually, it's because I blew off applying any cost correction
for this case in cost_mergejoin:
 * For SEMI and ANTI joins, only one inner tuple need be rescanned for * each group of same-keyed outer tuples
(assumingthat all joinquals * are merge quals).  This makes the effect small enough to ignore, * so we just set
rescannedtuples= 0.
 

Obviously that's not going to be good enough for production --- the
parenthetical assumption here is just wrong in the case at hand.

That doesn't seem to be the only issue in your example, but it's
definitely one of 'em.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
Next
From: Jeff Davis
Date:
Subject: Re: [PATCHES] GIN improvements