On 2013-12-10 16:09:02 -0500, Robert Haas wrote: > On Tue, Dec 10, 2013 at 4:30 AM, Peter Geoghegan <p...@heroku.com> wrote: > > I'm not sure that I agree, but there is anecdata that suggests that it > > isn't uncommon for these sorts of queries to be broken out when > > they're all traceable back to a single point in the application > > (apparently it's common for Django apps to do so, perhaps > > questionably). If we assume that doing what I've described has no real > > downside, then it would probably be worth implementing. Plus I'm > > pretty sure that tools that do regex normalization are already doing > > something analogous. Thoughts? > > Sounds like this: > > // What's the worst thing that could happen? > pandoras_box.open(); > > I am very wary of implementing special-case logic here even though I > know it could be useful to some people, simply because I fear that > there could be a near-infinite variety of situations where, in a > particular environment, a particular distinction isn't important. We > won't be serving anyone well if we ignore all of those distinctions, > because not everyone will want to ignore all of them. And adding a > configuration option for each one doesn't sound like a good idea, > either. *Maybe* this particular case is narrow enough that it's OK to > just ignore it unconditionally and maybe that'd be OK ... but I fear > this is a rathole.
FWIW, I hit exactly this issue every single time I have looked at pg_stat_statements in some client's database making it nearly useless for analysis. So improving it might be worthwile. On the other hand, so far all could fix their application in a reasonable amount of time to generate = ANY(array) queries instead. Which probably isn't a bad idea either, considering they now use far fewer prepared statements. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
