On Wed, Aug 30, 2017 at 5:38 PM, Robert Haas <robertmh...@gmail.com> wrote: > Wow. Just to be clear, I am looking for the BEST case for replacement > selection, not the worst case. But I would have expected that case to > be a win for replacement selection, and it clearly isn't. I can > reproduce your results here.
But I *was* trying to get a best case. That's why it isn't even worse. That's what the docs say the best case is, after all. This is the kind of thing that replacement selection actually did do better with on 9.6. I clearly remember Tomas Vondra doing lots of benchmarking, showing some benefit with RS with a work_mem of 8MB or less. As I said in my introduction on this thread, we weren't wrong to add replacement_sort_tuples to 9.6, given where things were with merging at the time. But, it does very much appear to create less than zero benefit these days. The picture changed. -- 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