From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redundant Result node |
Date: | 2024-08-23 03:08:47 |
Message-ID: | CAMbWs49QVFUdgG8K-hb5dL8Hv7h2rsEi+u32W7VdnAbsOJcT8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 22, 2024 at 3:34 PM Richard Guo <guofenglinux(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-08-23 03:19:17 | Re: Redundant Result node |
Previous Message | Tender Wang | 2024-08-23 02:44:19 | Re: [BUG] Fix DETACH with FK pointing to a partitioned table fails |