Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitb6423e9

Browse files
committed
Doc: fix ancient mistake, or at least obsolete info, in rules example.
The example of expansion of multiple views claimed that the resultingsubquery nest would not get fully flattened because of an aggregatefunction. There's no aggregate in the example, though, only a userdefined function confusingly named MIN(). In a modern server, thereason for the non-flattening is that MIN() is volatile, but I'munsure whether that was true back when this text was written.Let's reduce the confusion level by using LEAST() instead (whichwe didn't have at the time this example was created). And thenwe can just say that the planner will flatten the sub-queries, sothe rewrite system doesn't have to.Noted by Paul Jungwirth. This text is old enough to vote, soback-patch to all supported branches.Discussion:https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com
1 parent13e8b2e commitb6423e9

File tree

1 file changed

+8
-24
lines changed

1 file changed

+8
-24
lines changed

‎doc/src/sgml/rules.sgml

Lines changed: 8 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -341,17 +341,6 @@ CREATE RULE "_RETURN" AS ON SELECT TO myview DO INSTEAD
341341
than having many different ones that might mix up in mind.
342342
</para>
343343

344-
<para>
345-
For the example, we need a little <literal>min</literal> function that
346-
returns the lower of 2 integer values. We create that as:
347-
348-
<programlisting>
349-
CREATE FUNCTION min(integer, integer) RETURNS integer AS $$
350-
SELECT CASE WHEN $1 &lt; $2 THEN $1 ELSE $2 END
351-
$$ LANGUAGE SQL STRICT;
352-
</programlisting>
353-
</para>
354-
355344
<para>
356345
The real tables we need in the first two rule system descriptions
357346
are these:
@@ -414,7 +403,7 @@ CREATE VIEW shoe_ready AS
414403
rsh.sh_avail,
415404
rsl.sl_name,
416405
rsl.sl_avail,
417-
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
406+
least(rsh.sh_avail, rsl.sl_avail) AS total_avail
418407
FROM shoe rsh, shoelace rsl
419408
WHERE rsl.sl_color = rsh.slcolor
420409
AND rsl.sl_len_cm &gt;= rsh.slminlen_cm
@@ -593,7 +582,7 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
593582
rsh.sh_avail,
594583
rsl.sl_name,
595584
rsl.sl_avail,
596-
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
585+
least(rsh.sh_avail, rsl.sl_avail) AS total_avail
597586
FROM shoe rsh, shoelace rsl
598587
WHERE rsl.sl_color = rsh.slcolor
599588
AND rsl.sl_len_cm &gt;= rsh.slminlen_cm
@@ -613,7 +602,7 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
613602
rsh.sh_avail,
614603
rsl.sl_name,
615604
rsl.sl_avail,
616-
min(rsh.sh_avail, rsl.sl_avail) AS total_avail
605+
least(rsh.sh_avail, rsl.sl_avail) AS total_avail
617606
FROM (SELECT sh.shoename,
618607
sh.sh_avail,
619608
sh.slcolor,
@@ -640,16 +629,11 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
640629
</para>
641630

642631
<para>
643-
It turns out that the planner will collapse this tree into a
644-
two-level query tree: the bottommost <command>SELECT</command>
645-
commands will be <quote>pulled up</quote> into the middle
646-
<command>SELECT</command> since there's no need to process them
647-
separately. But the middle <command>SELECT</command> will remain
648-
separate from the top, because it contains aggregate functions.
649-
If we pulled those up it would change the behavior of the topmost
650-
<command>SELECT</command>, which we don't want. However,
651-
collapsing the query tree is an optimization that the rewrite
652-
system doesn't have to concern itself with.
632+
This might look inefficient, but the planner will collapse this into a
633+
single-level query tree by <quote>pulling up</quote> the subqueries,
634+
and then it will plan the joins just as if we'd written them out
635+
manually. So collapsing the query tree is an optimization that the
636+
rewrite system doesn't have to concern itself with.
653637
</para>
654638
</sect2>
655639

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp