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

From Simon Riggs
Subject Re: A better way than tweaking NTUP_PER_BUCKET
Date
Msg-id CA+U5nMKi_+40G9TL2mB8ixY7CHPt23Ye6cF2DzR1b0G82Duhmw@mail.gmail.com
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  (Atri Sharma <atri.jiit@gmail.com>)
Re: A better way than tweaking NTUP_PER_BUCKET  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 25 January 2014 22:33, Stephen Frost <sfrost@snowman.net> wrote:

> * Tom Lane (tgl@sss.pgh.pa.us) wrote:

>> 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.
>
> This I entirely agree with- more testing and more information on how
> such a change impacts other workloads would be great.  Unfortunately,
> while I've provided a couple of test cases and seen similar situations
> on IRC, this is very data-dependent which makes it difficult to have
> concrete answers for every workload.
>
> Still, I'll try and spend some time w/ pg_bench's schema definition and
> writing up some larger queries to run through it (aiui, the default set
> of queries won't typically result in a hashjoin) and see what happens
> there.

The case that action of some kind was needed was clear, for me.
Hopefully some small improvement can be found from that investigation,
even if the greatest gain is in some way under dispute.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: What is happening on buildfarm member crake?
Next
From: David Rowley
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)