On Sat, Apr 2, 2016 at 3:20 PM, Greg Stark <st...@mit.edu> wrote: > These are the averages across all queries across all data sets for the > run-time for the patch versus master (not patched 64 which I think is > the replacement_sort_mem=64MB which appears to not be a win). So even > in the less successful cases on average quicksort is faster than > replacement selection.
It's actually replacement_sort_mem=64 (64KB -- effectively disabled). So where that case does better or worse, which can only be when work_mem=8MB in practice, that's respectively good or bad for replacement selection. So, typically RS does better when there are presorted inputs with a positive (not inverse/DESC) correlation, and there is little work_mem. As I've said, this is where the CPU cache is large enough to fit the entire memtuples heap. "Padded" cases are mostly bad because they make the memtuples heap relatively small in each case. So with work_mem=32MB, you get a memtuples heap structure similar to work_mem=8MB. The padding pushes things out a bit further, which favors master. -- 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
