Re: Redundant Result node
От | Richard Guo |
---|---|
Тема | Re: Redundant Result node |
Дата | |
Msg-id | CAMbWs4_9Amakf6JWnzLuk=wfvjt35JiYVqz9prMaberRXHVO7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Redundant Result node (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Redundant Result node
|
Список | pgsql-hackers |
On Fri, Aug 23, 2024 at 11:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Richard Guo <guofenglinux@gmail.com> writes: > > ... 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. > > I'm not sure you're considering "efficiency" in the right light. > In my mind, any time we can postpone work from path-creation time > to plan-creation time, we're probably winning because we create > many more paths than plans. Perhaps that's wrong in this case, > but it's not anywhere near as obvious as you suggest. 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. Thanks Richard
В списке pgsql-hackers по дате отправления: