David Rowley <dgrowle...@gmail.com> writes:
> I see this is quite a fundamental change to how things currently work and
> it could cause planning to take place during the execution of PREPAREd
> statements, which might not impress people too much, but it would certainly
> fix the weird anomalies that I'm currently facing by trimming the plan at
> executor startup. e.g left over Sort nodes after a MergeJoin was removed.
> It would be interesting to hear Tom's opinion on this.
TBH I don't like this patch at all even in its current form, let alone
a form that's several times more invasive. I do not think there is a
big enough use-case to justify such an ad-hoc and fundamentally different
way of doing things. I think it's probably buggy as can be --- one thing
that definitely is a huge bug is that it modifies the plan tree in-place,
ignoring the rule that the plan tree is read-only to the executor.
Another question is what effect this has on EXPLAIN; there's basically
no way you can avoid lying to the user about what's going to happen at
runtime.
One idea you might think about to ameliorate those two objections is two
separate plan trees underneath an AlternativeSubPlan or similar kind of
node.
At a more macro level, there's the issue of how can the planner possibly
make intelligent decisions at other levels of the join tree when it
doesn't know the cost of this join. For that matter there's nothing
particularly driving the planner to arrange the tree so that the
optimization is possible at all.
Bottom line, given all the restrictions on whether the optimization can
happen, I have very little enthusiasm for the whole idea. I do not think
the benefit will be big enough to justify the amount of mess this will
introduce.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
