Re: Redundant Result node
От | Richard Guo |
---|---|
Тема | Re: Redundant Result node |
Дата | |
Msg-id | CAMbWs49QVFUdgG8K-hb5dL8Hv7h2rsEi+u32W7VdnAbsOJcT8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Redundant Result node (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Redundant Result node
|
Список | 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 по дате отправления: