On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers