Re: Funny representation in pg_stat_statements.query.

On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> This apparently seems that the query passing through
> pg_stat_statements twice during single execution. Actually, the
> first one is a by-product of planning (simplify_function) and the
> second is just what expected by users. It surely not a problem
> after knowing what is occurring but it should seem quite strange
> for those who don't know of that. Of couse there might be others
> than this simplification executing internally-generated query
> during planning, too, yet I haven't noticed. It's puzzling how to
> deal with it.

I was aware of the fact that those could get in there from planning.
Another fun trick is that a pg_stat_statements_reset() containing
query is perhaps recorded as a new entry for the parse analysis hook,
and always as a new entry for the executor hook. Because, of course,
it vanishes in the interim. So "select 1,2,3,
pg_stat_statements_reset();" will never have any '?' characters for
constant values.

In practice everything mostly works out. I use pg_stat_statements
quite a bit, and I only very occasionally see weirdness like complete
failure to normalize a query string (it is a limitation of
pg_stat_statements that this can happen with very low probability).
It's a bit of a kludge, but the query string is always just strictly
speaking a convenience to help the user understand what the entry is.
Although, I suppose, most people don't realize that.

--
Peter Geoghegan