On Thu, Mar 10, 2016 at 10:39 AM, Greg Stark <st...@mit.edu> wrote: > I want to rerun these on a dedicated machine and with trace_sort > enabled so that we can see how many merge passes were actually > happening and how much I/O was actually happening.
Putting the results in context, by keeping trace_sort output with the results is definitely a good idea here. Otherwise, it's almost impossible to determine what happened after the fact. I have had "trace_sort = on" in my dev postgresql.conf for some time now. :-) When I produce my next revision, we should focus on regressions at the low end, like the 4MB work_mem for multiple GB table size cases you show here. So, I ask that any benchmarks that you or Tomas do look at that first and foremost. It's clear that in high memory environments the patch significantly improves performance, often by as much as 2.5x, and so that isn't really a concern anymore. I think we may be able to comprehensively address Robert's concerns about regressions with very little work_mem and lots of data by fixing a problem with polyphase merge. More to come soon. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers