Re: Redundant Result node - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Redundant Result node
Date
Msg-id dd8328a6-4602-48ca-88c8-4d7d5d16880f@eisentraut.org
Whole thread Raw
In response to Redundant Result node  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
On 23.08.24 10:27, Richard Guo wrote:
> On Fri, Aug 23, 2024 at 11:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Richard Guo <guofenglinux@gmail.com> writes:
>>> I agree that it’s always desirable to postpone work from path-creation
>>> time to plan-creation time.  In this case, however, it’s a little
>>> different.  The projection step could actually be avoided from the
>>> start if we perform the correct check in create_ordered_paths.
>>
>> Well, the question is how expensive is the "correct check" compared
>> to what we're doing now.  It might be cheaper than creating an extra
>> level of path node, or it might not.  An important factor here is
>> that we'd pay the extra cost of a more complex check every time,
>> whether it avoids creation of an extra path node or not.
> 
> Fair point.  After looking at the code for a while, I believe it is
> sufficient to compare PathTarget.exprs after we've checked that the
> two targets have different pointers.

-        if (sorted_path->pathtarget != target)
+        if (sorted_path->pathtarget != target &&
+            !equal(sorted_path->pathtarget->exprs, target->exprs))
              sorted_path = apply_projection_to_path(root, ordered_rel,

equal() already checks whether both pointers are equal, so I think this 
could be simplified to just

     if (!equal(sorted_path->pathtarget->exprs, target->exprs))




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Next
From: "Wetmore, Matthew (CTR)"
Date:
Subject: Re: Non-trivial condition is only propagated to one side of JOIN