On Mon, Jan 9, 2017 at 12:25 PM, Peter Eisentraut
<peter.eisentraut@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