From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: [HACKERS] Planning counters in pg_stat_statements |
Date: | 2018-01-13 00:36:17 |
Message-ID: | 28980.1515803777@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> writes:
> I checked the latest patch and it is working fine and I don't have any
> further comments. Marked the patch as "ready for committer".
I started to look at this patch, and I'm not entirely convinced whether
it is a good thing for the planner_hook to bump nested_level. ISTM
that will change behavior in some ways, in particular when the planner
chooses to evaluate an immutable or stable function that runs the
executor (probably via SPI). Before, that execution would have been
regarded as a top-level call, now it will not be. Maybe that's fine,
but did anyone think hard about it?
A possible alternative behavior is for planner_hook to maintain its
own nesting depth counter, separate from the one for execution
nesting depth. I'm not sure if that's better or not.
Discuss ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-13 01:16:25 | Re: [HACKERS] Planning counters in pg_stat_statements |
Previous Message | Claudio Freire | 2018-01-12 23:44:45 | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |