On Mon, Dec 14, 2015 at 7:22 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Mon, Dec 14, 2015 at 6:58 PM, Greg Stark <st...@mit.edu> wrote: >> I ran sorts with various parameters on my small NAS server. > > ... > >> without the extra memory optimizations. > > Thanks for taking the time to benchmark the patch! > > While I think it's perfectly fair that you didn't apply the final > on-the-fly merge "memory pool" patch, I also think that it's quite > possible that the regression you see at the very low end would be > significantly ameliorated or even eliminated by applying that patch, > too. After all, Jeff Janes had a much harder time finding a > regression, probably because he benchmarked all patches together.
The regression I found when building an index on a column of 400,000,000 md5(random()::text) with 64MB maintenance_work_mem was not hard to find at all. I still don't understand what is going on with it, but it is reproducible. Perhaps it is very unlikely and I just got very lucky in finding it immediately after switching to that data-type for my tests, but I wouldn't assume that on current evidence. If we do think it is important to almost never cause regressions at the default maintenance_work_mem (I am agnostic on the importance of that), then I think we have more work to do here. I just don't know what that work is. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
