From b6423e92abfadaa1ed9642319872aa1654403cd6 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 11 Nov 2019 14:39:54 -0500 Subject: [PATCH] Doc: fix ancient mistake, or at least obsolete info, in rules example. The example of expansion of multiple views claimed that the resulting subquery nest would not get fully flattened because of an aggregate function. There's no aggregate in the example, though, only a user defined function confusingly named MIN(). In a modern server, the reason for the non-flattening is that MIN() is volatile, but I'm unsure whether that was true back when this text was written. Let's reduce the confusion level by using LEAST() instead (which we didn't have at the time this example was created). And then we can just say that the planner will flatten the sub-queries, so the rewrite system doesn't have to. Noted by Paul Jungwirth. This text is old enough to vote, so back-patch to all supported branches. Discussion: https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com --- doc/src/sgml/rules.sgml | 32 ++++++++------------------------ 1 file changed, 8 insertions(+), 24 deletions(-) diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 4e20664ea1..2610645663 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -341,17 +341,6 @@ CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD than having many different ones that might mix up in mind. - -For the example, we need a little min function that -returns the lower of 2 integer values. We create that as: - - -CREATE FUNCTION min(integer, integer) RETURNS integer AS $$ - SELECT CASE WHEN $1 < $2 THEN $1 ELSE $2 END -$$ LANGUAGE SQL STRICT; - - - The real tables we need in the first two rule system descriptions are these: @@ -414,7 +403,7 @@ CREATE VIEW shoe_ready AS rsh.sh_avail, rsl.sl_name, rsl.sl_avail, - min(rsh.sh_avail, rsl.sl_avail) AS total_avail + least(rsh.sh_avail, rsl.sl_avail) AS total_avail FROM shoe rsh, shoelace rsl WHERE rsl.sl_color = rsh.slcolor AND rsl.sl_len_cm >= rsh.slminlen_cm @@ -593,7 +582,7 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail, rsh.sh_avail, rsl.sl_name, rsl.sl_avail, - min(rsh.sh_avail, rsl.sl_avail) AS total_avail + least(rsh.sh_avail, rsl.sl_avail) AS total_avail FROM shoe rsh, shoelace rsl WHERE rsl.sl_color = rsh.slcolor AND rsl.sl_len_cm >= rsh.slminlen_cm @@ -613,7 +602,7 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail, rsh.sh_avail, rsl.sl_name, rsl.sl_avail, - min(rsh.sh_avail, rsl.sl_avail) AS total_avail + least(rsh.sh_avail, rsl.sl_avail) AS total_avail FROM (SELECT sh.shoename, sh.sh_avail, sh.slcolor, @@ -640,16 +629,11 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail, - It turns out that the planner will collapse this tree into a - two-level query tree: the bottommost SELECT - commands will be pulled up into the middle - SELECT since there's no need to process them - separately. But the middle SELECT will remain - separate from the top, because it contains aggregate functions. - If we pulled those up it would change the behavior of the topmost - SELECT, which we don't want. However, - collapsing the query tree is an optimization that the rewrite - system doesn't have to concern itself with. + This might look inefficient, but the planner will collapse this into a + single-level query tree by pulling up the subqueries, + and then it will plan the joins just as if we'd written them out + manually. So collapsing the query tree is an optimization that the + rewrite system doesn't have to concern itself with.