From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: read-only planner input |
Date: | 2005-03-21 01:36:01 |
Message-ID: | 9123.1111368961@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> Here's one idea to fix this: when planning a Query, transform the Query
> into a "PlannedQuery". This would essentially be the same as the
> QueryState we discussed earlier, except that we would also walk through
> the Query and adjust references to nested Queries to refer to
> PlannedQueries instead (so RTEs for subqueries would reference the
> PlannedQuery, not the Query, for example). There would then be a
> "planned query walker" that would walk both the original query and
> additional planner-specific working state, and so on.
> Perhaps we could use some trickery to avoid the PlannedQuery vs. Query
> distinction when a particular piece of code doesn't care, by making
> Query the first field of PlannedQuery. In other words:
> struct PlannedQuery {
> Query q;
> /* other fields */
> };
> So we could treat a PlannedQuery * like a Query *. I don't really like
> this solution.
No. At that point you've essentially booted away the entire point of
the change :-(
IIRC one of the main reasons for wanting to make the planner read-only
is so that it does *not* modify subquery RTE contents --- there are all
sorts of uglinesses involved in the fact that it presently does, mainly
having to be sure that we plan each subquery exactly once. If we go
this route then we won't be able to fix any of that stuff.
> Another possibility would be to punt, and keep in_info_list as part of
> Query.
That's seeming like the path of least resistance at the moment ... but
it still isn't going to solve the subquery RTE issues. I'm feeling a
bit discouraged about this concept right now ... maybe we need to back
off and think about a fresh start.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-03-21 02:11:15 | Re: Avoiding unnecessary writes during relation drop and truncate |
Previous Message | Qingqing Zhou | 2005-03-21 01:32:23 | Re: what to do with backend flowchart |