Re: bad estimation together with large work_mem generates terrible slow hash joins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bad estimation together with large work_mem generates terrible slow hash joins
Date
Msg-id 15702.1410443999@sss.pgh.pa.us
Whole thread Raw
In response to Re: bad estimation together with large work_mem generates terrible slow hash joins  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: bad estimation together with large work_mem generates terrible slow hash joins
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> With the exception of ExecChooseHashTableSize() and a lot of stylistic
> issues along the lines of what I've already complained about, this
> patch seems pretty good to me.  It does three things:
> ...
> (3) It allows the number of batches to increase on the fly while the
> hash join is in process.  This case arises when we initially estimate
> that we only need a small hash table, and then it turns out that there
> are more tuples than we expect.  Without this code, the hash table's
> load factor gets too high and things start to suck.

Pardon me for not having read the patch yet, but what part of (3)
wasn't there already?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Aussie timezone database changes incoming
Next
From: Andres Freund
Date:
Subject: Re: Scaling shared buffer eviction