On Sat, Apr 2, 2016 at 3:22 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Sat, Apr 2, 2016 at 3:20 PM, Greg Stark <st...@mit.edu> wrote: >> There are also some weird cases in this list where there's a >> significant regression at 32MB but not at 8MB. I would like to see >> 16MB and perhaps 12MB and 24MB. They would help understand if these >> are just quirks or there's a consistent pattern. > > I'll need to drill down to trace_sort output to see what happened there.
I looked into this. I too noticed that queries like "SELECT a FROM int_test UNION SELECT a FROM int_test_padding" looked strangely faster for 128MB + high_cardinality_almost_asc + i5 for master branch. This made the patch look relatively bad for the test with those exact properties only; the patch was faster with both lower and higher work_mem settings than 128MB. There was a weird spike in performance for the master branch only. Having drilled down to trace_sort output, I think I know roughly why. I see output like this: 1459308434.753 2016-03-30 05:27:14 CEST STATEMENT: SELECT * FROM (SELECT a FROM int_test UNION SELECT a FROM int_test_padding OFFSET 1e10) ff; I think that this is invalid, because the query was intended as this: SELECT * FROM (SELECT * FROM (SELECT a FROM int_test UNION SELECT a FROM int_test_padding) gg OFFSET 1e10) ff; This would have controlled for client overhead, per my request to Tomas, without altering the "underlying query" that you see in the final spreadsheet. I don't have an exact explanation for why you'd see this spike at 128MB for the master branch but not the other at the moment, but it seems like that one test is basically invalid, and should be discarded. I suspect that the patch didn't see its own similar spike due to my changes to cost_sort(), which reflected that sorts don't need to do so much expensive random I/O. This is the only case that I saw that was not more or less consistent with my expectations, which is good. -- 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