Re: Funny representation in pg_stat_statements.query. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Funny representation in pg_stat_statements.query.
Date
Msg-id CAM3SWZS5+oT4RhxkroBSyvjv8tCdcs45x+RAtsdV4his56JfnA@mail.gmail.com
Whole thread Raw
In response to Re: Funny representation in pg_stat_statements.query.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On Tue, Jan 21, 2014 at 7:29 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [bug fix] pg_ctl always uses the same event source
Next
From: Amit Kapila
Date:
Subject: Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it