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+U5nMLzaRc3_g2+4h_9dPPoJD3X05bQ-Jx9fK5VphFypazDkg@mail.gmail.com
Whole thread Raw
In response to Re: A better way than tweaking NTUP_PER_BUCKET  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: A better way than tweaking NTUP_PER_BUCKET
List pgsql-hackers
On 25 January 2014 23:08, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

I don't see anything for 9.4 in here now.

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



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: inherit support for foreign tables
Next
From: Kouhei Kaigai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)