Neil Conway <[EMAIL PROTECTED]> 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 nest
Tom Lane wrote:
That's a bit nasty. I'm fairly sure that I added in_info_list to the
walker recursion because I had to; I don't recall the exact scenario,
but I think it needs to be possible to reassign relation numbers
within that data structure if we are doing it elsewhere in a query
tree.
It wa
Neil Conway <[EMAIL PROTECTED]> writes:
> I've got most of this finished; I'll post a patch soon. One issue I ran
> into is how to handle query_tree_mutator() and query_tree_walker(): they
> both expect to be able to traverse a Query's in_info_list, which my
> patch moves into the QueryState str
Tom Lane wrote:
I'd go with PlannerState. QueryState for some reason sounds more like
execution-time state.
Well, not to me :) It just makes sense to me that QueryState as the
working state associated with a Query. Not sure it makes a big
difference, though.
Pulling the "planner internal" stuff
Neil Conway <[EMAIL PROTECTED]> writes:
> ... By not well-defined, I meant that
> if the user is changing GUC variables on the fly, they can't rely on
> their prepared query being planned under any particular datestyle (or
> search path, etc.), since they can't really predict when replanning wil
Tom Lane wrote:
It is well defined, because we insist that the gram.y transformation not
depend on any changeable state.
That's my point -- whether we begin from the query string or the raw
parsetree shouldn't make a difference. By not well-defined, I meant that
if the user is changing GUC variab
Neil Conway <[EMAIL PROTECTED]> writes:
> Oliver Jowett wrote:
>> What happens if (for example) DateStyle changes between the two parses?
> I'm don't think recreating the plan from the query string changes this
> fundamentally -- the interaction between (for example) GUC variables and
> prepare
Oliver Jowett wrote:
What happens if (for example) DateStyle changes between the two parses?
From my original email:
This is the common case of a more general problem: a query plan depends
on various parts of the environment at plan-creation time. That
environment includes the definitions of datab
Tom Lane wrote:
You could make a
good case that we just ought to save query text and start from there in
any replanning; it'd be the most compact representation, the easiest to
copy around, and the least likely to break.
What happens if (for example) DateStyle changes between the two parses?
(not
Tom Lane wrote:
I don't believe there is any very significant amount of planner work
that is completely independent of any external database object. For
that matter, even the rewriter needs to be rerun when any views or
defaults change in the query. And for that matter, even the parse
analysis ph
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, I wonder whether it would be possible to move some preprocessing
> from the early stages of the planner to a "preprocessing" phase that
> would run after the rewriter but before the planner proper. The
> preprocessor would maintain the essential pro
Neil Conway <[EMAIL PROTECTED]> writes:
> I just noticed that there is a `PlanState' node in the executor, of all
> places. I'm thinking of using `QueryState' instead -- this parallels the
> usage of PlanState in the executor, to some degree (PlanState holds some
> of the state of the executor a
Qingqing Zhou wrote:
So is this change the preparation work of caching query plans? Like cleaning
the plans so they could be well shared?
Yeah, it is somewhat related to the centralized plan caching module that
Tom and I have been discussing in the "cached plan invalidation" thread.
When a cached
"Neil Conway" <[EMAIL PROTECTED]>
> I've been taking a look at how to stop the planner from scribbling on
> its input. This is my first modification of any significance to the
> planner, so don't hesitate to tell me what I've gotten wrong :)
>
So is this change the preparation work of caching quer
Neil Conway wrote:
(b) should be pretty easy to solve; we can create a per-Query PlanState
struct that contains this information, as well as holding a pointer to
the Query (and perhaps the in-construct Plan tree).
I just noticed that there is a `PlanState' node in the executor, of all
places. I'
I've been taking a look at how to stop the planner from scribbling on
its input. This is my first modification of any significance to the
planner, so don't hesitate to tell me what I've gotten wrong :)
I think the planner makes two kinds of modifications to the input Query:
(a) rewriting of the
16 matches
Mail list logo
