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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date: 2012-03-29 01:09:41
Message-ID: 8270.1332983381@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> doc-patch is attached. I'm not sure if I got the balance right - it
> may be on the verbose side.

Thanks. I've committed the patch along with the docs, after rather
heavy editorialization.

There remain some loose ends that should be worked on but didn't seem
like commit-blockers:

1. What to do with EXPLAIN, SELECT INTO, etc. We had talked about
tweaking the behavior of statement nesting and some other possibilities.
I think clearly this could use improvement but I'm not sure just how.
(Note: I left out the part of your docs patch that attempted to explain
the current behavior, since I think we should fix it not document it.)

2. Whether and how to adjust the aging-out of sticky entries. This
seems like a research project, but the code impact should be quite
localized.

BTW, I eventually concluded that the parameterization testing we were
worried about before was a red herring. As committed, the patch tries
to store a normalized string if it found any deletable constants, full
stop. This seems to me to be correct behavior because the presence of
constants is exactly what makes the string normalizable, and such
constants *will* be ignored in the hash calculation no matter whether
there are other parameters or not.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joachim Wieland 2012-03-29 01:12:31 Re: patch for parallel pg_dump
Previous Message Andrew Dunstan 2012-03-29 00:46:00 Re: patch for parallel pg_dump