On Mon, Jan 9, 2017 at 12:25 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 1/7/17 10:01 PM, Peter Geoghegan wrote: >> It occurs to me that the comparison caching stuff added by commit >> 0e57b4d8b needs to be considered here, too.
> That might be worth looking into, but it seems a bit daunting to > construct a benchmark specifically for this, unless we have the one that > was originally used lying around somewhere. The benchmark used when 0e57b4d8b went in only had to prove that there was no measurable overhead when the optimization didn't help (It was quite clear that it was worthwhile in good cases). I think that comparison caching will continue to be about as effective as before in good cases, but you don't do comparison caching anymore. That might be fine, but let's be sure that that's the right trade-off. To demonstrate the effectiveness of the patch, I used this cities sample data: http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/data/cities.dump Test query: select country, province, count(*) from cities group by rollup (country, province); This was shown to be about 25% faster, although that was with abbreviated keys (plus caching of abbreviated keys), and not just the comparison caching optimization. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers