On Tue, Nov 24, 2015 at 2:25 PM, Greg Stark <st...@mit.edu> wrote: > On Tue, Nov 24, 2015 at 7:53 AM, Peter Geoghegan <p...@heroku.com> wrote: >> * How do other people feel about this? Personally, I've seen enough >> problems of this kind in the field that "slippery slope" arguments >> against this don't seem very compelling.
+1 for changing jumbling logic to consider any number of constants as identical. > I have also seen code where I would have needed *not* to have this > jumbling though. I think this is a general problem with jumbling that > there needs to be some kind of intelligence that deduces when it's > important to break out the statistics by constant. In my case it was > an IN query where specific values were very common but others very > rare. Partial indexes ended up being the solution and we had to > identify which partial indexes were needed. This is an issue with jumbling in general and very vaguely related to merging the number of constants in IN. I think a better solution for this type of issue would be a way to sample the parameter values and possibly EXPLAIN ANALYZE results to logs. Having runtime intelligence in PostgreSQL that would be capable of distinguishing interesting variations from irrelevant doesn't seem like a feasible plan. In my view the best we could do is to aim to have entries roughly correspond to application query invocation points and leave the more complex statistical analysis use cases to more specialized tools. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
