Re: A better way than tweaking NTUP_PER_BUCKET - Mailing list pgsql-hackers

From Tom Lane
Subject Re: A better way than tweaking NTUP_PER_BUCKET
Date
Msg-id 10230.1390687990@sss.pgh.pa.us
Whole thread Raw
In response to Re: A better way than tweaking NTUP_PER_BUCKET  (Stephen Frost <sfrost@snowman.net>)
Responses Re: A better way than tweaking NTUP_PER_BUCKET
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Bruce Momjian (bruce@momjian.us) wrote:
>> Uh, were are we on this?  Is it a TODO?

> I've been strongly considering my previous patch which tweaked
> NTUP_PER_BUCKET to '1' (instead of the default '10') when there's
> sufficient work_mem for it.  There was recently another complaint on IRC
> about our tendency to hash the larger partition rather than the smaller
> one which I believe would be resolved by doing so.

> The main thing holding me back has been concern that there may be cases
> which perform worse with the change, either because hashing the larger
> partition actually ended up being faster or due to the increase in
> memory usage.

> In the end, I believe we absolutely should do something about this.
> Hashing a 64M-row table (requiring upwards of 8G) instead of hashing
> a 2M-row table is really bad of us.

Huh?  I don't see anything in the thread suggesting that we're doing that,
or that changing NTUP_PER_BUCKET would fix it if we do.  Are you thinking
of some other discussion?

AFAICT, there was no consensus in this thread on what to do, which
probably has something to do with the lack of concrete performance
tests presented to back up any particular proposal.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: libpq: Support TLS versions beyond TLSv1.