Re: A better way than tweaking NTUP_PER_BUCKET

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: A better way than tweaking NTUP_PER_BUCKET
Дата
Msg-id CA+U5nMLzaRc3_g2+4h_9dPPoJD3X05bQ-Jx9fK5VphFypazDkg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A better way than tweaking NTUP_PER_BUCKET  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: A better way than tweaking NTUP_PER_BUCKET  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: inherit support for foreign tables
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Custom Scan APIs (Re: Custom Plan node)