Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: "Mario Weilguni" <mario(dot)weilguni(at)icomedias(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)
Date: 2005-11-29 00:34:21
Message-ID: 17684.1133224461@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> I suspect this is obvious but since you asked, there isn't any way to keep
> around the hash table and just reuse it repeatedly instead of having to rescan
> the data over and over is there?

We already do that when possible --- which it's not in the particular
case at hand, because there's an outer-query parameter used in the
hashed subplan.

It occurs to me that the planner ought to favor putting parameterized
subplans on the outside of a hash join instead of the inside, so as to
make reuse more likely. Not sure how to factor that into the cost
model though.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-11-29 00:34:45 Re: gprof SELECT COUNT(*) results
Previous Message Greg Stark 2005-11-29 00:25:58 Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)