From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-28 14:45:25 |
Message-ID: | CAEYLb_VPqXP5UwzcFHarV4c87ocn8N1H79KexgY3W9ZE2AREEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28 March 2012 15:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> That's been an issue right along for cases such as EXPLAIN and EXECUTE,
> I believe.
Possible, since I didn't have test coverage for either of those 2 commands.
Perhaps the right thing is to consider such executor calls
> as nested statements --- that is, the ProcessUtility hook ought to
> bump the nesting depth too.
That makes a lot of sense, but it might spoil things for the
pg_stat_statements.track = 'top' + pg_stat_statements.track_utility =
'on' case. At the very least, it's a POLA violation, to the extent
that if you were going to do this, you might mandate that nested
statements be tracked along with utility statements (probably while
defaulting to having both off, which would be a change).
Since you've already removed the intoClause chunk, I'm not sure how
far underway the review effort is - would you like me to produce a new
revision, or is that unnecessary?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2012-03-28 14:46:18 | Re: triggers and inheritance tree |
Previous Message | Noah Misch | 2012-03-28 14:44:32 | Re: 9.2 commitfest closure (was Command Triggers, v16) |