Re: Redundant Result node - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Redundant Result node
Date
Msg-id CAMbWs49QVFUdgG8K-hb5dL8Hv7h2rsEi+u32W7VdnAbsOJcT8A@mail.gmail.com
Whole thread Raw
In response to Redundant Result node  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Redundant Result node
List pgsql-hackers
On Thu, Aug 22, 2024 at 3:34 PM Richard Guo <guofenglinux@gmail.com> wrote:
>     /* Add projection step if needed */
>     if (sorted_path->pathtarget != target)
>         sorted_path = apply_projection_to_path(root, ordered_rel,
>                                                sorted_path, target);
>
> This does not seem right to me, as PathTargets are not canonical, so
> we cannot guarantee that two identical PathTargets will have the same
> pointer.  Actually, for the query above, the two PathTargets are
> identical but have different pointers.

FWIW, the redundant-projection issue is more common in practice than I
initially thought.  For a simple query as below:

explain (verbose, costs off) select a from t order by 1;
         QUERY PLAN
----------------------------
 Sort
   Output: a
   Sort Key: t.a
   ->  Seq Scan on public.t
         Output: a
(5 rows)

... we'll always make a separate ProjectionPath on top of the SortPath
in create_ordered_paths.  It’s only when we create the plan node for
the projection step in createplan.c that we realize a separate Result
is unnecessary.  This is not efficient.

Thanks
Richard



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails
Next
From: Tom Lane
Date:
Subject: Re: Redundant Result node