Horton

Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Daniel Farina <daniel@heroku.com>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-28T14:57:51Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.

  2. Extend the parser location infrastructure to include a location field in

  3. Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant

A couple other issues about this patch ...

Is there any actual benefit in providing the
"pg_stat_statements.string_key" GUC?  It looks to me more like something
that was thrown in because it was easy than because anybody would want
it.  I'd just as soon leave it out and avoid the incremental API
complexity increase.  (While on that subject, I see no documentation
updates in the patch...)

Also, I'm not terribly happy with the "sticky entries" hack.  The way
you had it set up with a 1e10 bias for a sticky entry was completely
unreasonable IMO, because if the later pgss_store call never happens
(which is quite possible if the statement contains an error detected
during planning or execution), that entry is basically never going to
age out, and will just uselessly consume a precious table slot for a
long time.  In the extreme, somebody could effectively disable query
tracking by filling the hashtable with variants of "SELECT 1/0".
The best quick answer I can think of is to reduce USAGE_NON_EXEC_STICK
to maybe 10 or so, but I wonder whether there's some less klugy way to
get the result in the first place.  I thought about keeping the
canonicalized query string around locally in the backend rather than
having the early pgss_store call at all, but am not sure it's worth
the complexity of an additional local hashtable or some such to hold
such pending entries.

			regards, tom lane