Re: Funny representation in pg_stat_statements.query.

Hi, considering on pg_stat_statements itself,

pg> There was a more obvious case of this that I noticed during the
pg> development of pg_stat_statements query normalization. As you may have
pg> noticed, that was addressed by this commit:
pg> 
pg> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5d3fcc4c2e137417ef470d604fee5e452b22f6a7

Not at all :-) mmm.. Can there be more?

By the way, another kind of subtle behavior of pg_stat_statements
I've seen but you don't seem to have noticed or appreciated is
that about the function simplification in planner.

On the current 9.4dev head on master, pg_stat_statements behaves
as below,

=# select pg_stat_statements_reset();
=# select log(1.5);
=# select query from pg_stat_statements;              query                
------------------------------------select pg_catalog.log(?, $1)select log(?);select pg_stat_statements_reset();

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.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center