Re: read-only planner input

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

In response to

Browse pgsql-hackers by date

  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