On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> It strikes me that if we really want to restructure things to divide
>> client interaction from other query-processing routines, we should
>> create another file, say src/backend/tcop/queries.c; this would have
>> stuff like pg_plan_query, pg_plan_queries, pg_rewrite_query, and the
>> other things that the patch was evicting from postgres.c (plus, I
>> imagine, a bunch of other stuff that I may be missing). In fact, if we
>> go down this route, there would be no point in removing
>> pg_parse_and_rewrite; we would just move it to this new module.
>
> Yeah, possibly that would be a good idea.
>
> To my mind, the first thing that has to be resolved before messing
> around in this area is whether or not we want the logging/statistics
> behavior of these functions to apply when they are used in contexts
> other than interactive queries. Personally I would vote no, mainly
> because I don't think that behavior is very sensible in nested
> execution. If that is the decision, then probably these functions
> should stay where they are and as they are, and we just deprecate
> outside use of them. I'm not sure whether there's enough left after
> deleting the logging/statistics behavior to justify making exported
> versions, as opposed to just having the callers call the next-layer-down
> functionality directly.
It looks to me like the log_planner_stats stuff will blow up in nested
execution. So there's certainly no point in doing that.
The debug_print_plan stuff *might* be useful in nested execution...
although I'm not convinced. Not too many people are probably going to
use this at all, since the output is not human-readable.
I'm not real sure about the dtrace probes. If they are useful in
nested execution, we could move them down a bit (e.g. put
TRACE_POSTGRESQL_QUERY_PLAN_START/END into planner()).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
