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
|
Список | 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 по дате отправления: