Re: Top-N sorts verses parallelism
От | Amit Kapila |
---|---|
Тема | Re: Top-N sorts verses parallelism |
Дата | |
Msg-id | CAA4eK1Jzdg3baQRqyGSQj94=sQL2QWUtEpYd2Kko35bNqSLeag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Top-N sorts verses parallelism (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, Dec 19, 2017 at 5:24 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Mon, Dec 18, 2017 at 9:29 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> I went through the callers to create_sort_path and the only one that >> looks like it can pass a limit is the one you and Jeff already >> identified. So I think the question is just whether >> create_gather_merge_path needs a similar fix. > > I might be missing something, but it looks like there are no cases > where we have a limit_tuples value we could use AND we're relying on > create_gather_merge_path's own ability to create sort paths. So I > suspect there is no reason to change create_gather_merge_path itself > to deal with tuple limits. > Exactly. I was about to post the same and my analysis results are same as yours. I think this raises the question, do we really need cost_sort at that place and if so for which case? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: