From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Steve Singer <ssinger_pg(at)sympatico(dot)ca>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: Fix snapshot taking inconsistencies |
Date: | 2011-01-30 22:53:39 |
Message-ID: | AANLkTiku6RGbA-n++iu6NmL6gg9AS8FmXOvLu_KsPpbd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 20, 2010 at 6:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-30 22:55:51 | Re: autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.) |
Previous Message | Jeff Davis | 2011-01-30 22:52:01 | Re: WIP: RangeTypes |