Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> I'm reading the docs about the Postgres Rule system here:
> https://www.postgresql.org/docs/12/rules-views.html
> That page says:
>> It turns out that the planner will collapse this tree into a two-level query tree: the bottommost SELECT commands
willbe “pulled up” into the middle SELECT since there's no need to process them separately. But the middle SELECT will
remainseparate from the top, because it contains aggregate functions. If we pulled those up it would change the
behaviorof the topmost SELECT, which we don't want.
> But I don't see an aggregate function. Is it referring to MIN?
Perhaps. Digging in the git history, that text seems to be mine
(commit 1045304a3), but the example that it's talking about was
pre-existing. I think I might've just misread it. It's also
likely (assuming that I was documenting a behavior that I actually
saw at the time) that the real issue is that MIN(), as presented,
defaults to being volatile which would also prevent such flattening.
But this example is so old that I'm not sure whether that particular
optimization behavior existed then.
I'm inclined to:
(1) get rid of the example's MIN() function in favor of using
LEAST(), which is standard and less confusing;
(2) change the text to just say that the planner flattens these
subqueries, so we don't pay any execution-time penalty from the
way the view replacements are handled.
regards, tom lane
