Re: [HACKERS] [PATCH] Incremental sort
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] [PATCH] Incremental sort |
Дата | |
Msg-id | 20180407160946.w7renfifan2ssrng@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Incremental sort (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2018-04-07 12:06:52 -0400, Tom Lane wrote: > Alexander Korotkov <a.korotkov@postgrespro.ru> writes: > > On Wed, Mar 28, 2018 at 6:38 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> > > wrote: > >> Can we have a recap on what the patch *does*? > > > Ggeneral idea hasn't been changed much since first email. > > Incremental sort gives benefit when you need to sort your dataset > > by some list of columns while you alredy have input presorted > > by some prefix of that list of columns. Then you don't do full sort > > of dataset, but rather sort groups where values of prefix columns > > are equal (see header comment in nodeIncremenalSort.c). > > I dunno, how would you estimate whether this is actually a win or not? > I don't think our model of sort costs is anywhere near refined enough > or accurate enough to reliably predict whether this is better than > just doing it in one step. Even if the cost model is good, it's not > going to be better than our statistics about the number/size of the > groups in the first column(s), and that's a notoriously unreliable stat. > > Given that we already have more than enough dubious patches that have > been shoved in in the last few days, I'd rather not pile on stuff that > there's any question about. I don't disagree with any of that. Just wanted to pipe up to say that there's a fair argument to be made that this patch, which has lingered for years, "deserves" more to mature in tree than some of the rest. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: