On Wed, Mar 30, 2016 at 7:23 AM, Peter Geoghegan <p...@heroku.com> wrote: > Anyway, what I liked about Greg's approach to finding regressions at > the low end was that when testing, he used the cheapest possible VM > available on Google's cloud platform. When testing the low end, he had > low end hardware to go with the low end work_mem settings. This gave > the patch the benefit of using quicksort to make good use of what I > assume is a far smaller L2 cache; certainly nothing like 6MB or 12MB. > I think Greg might have used a home server to test my patch in [1], > actually, but I understand that it too was suitably low-end.
I'm sorry I was intending to run those benchmarks again this past week but haven't gotten around to it. But my plan was to run them on a good server I borrowed, an i7 with 8MB cache. I can still go ahead with that but I can also try running it on the home server again too if you want (and AMD N36L with 1MB cache). But even for the smaller machines I don't think we should really be caring about regressions in the 4-8MB work_mem range. Earlier in the fuzzer work I was surprised to find out it can take tens of megabytes to compile a single regular expression (iirc it was about 30MB for a 64-bit machine) before you get errors. It seems surprising to me that a single operator would consume more memory than an ORDER BY clause. I was leaning towards suggesting we just bump up the default work_mem to 8MB or 16MB. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
