Re: A better way than tweaking NTUP_PER_BUCKET

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: What is happening on buildfarm member crake?
Следующее
От: David Rowley
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)