Re: [HACKERS] [PATCH] Incremental sort - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [PATCH] Incremental sort
Date
Msg-id 16646.1523117212@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Incremental sort  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] [PATCH] Incremental sort  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] [PATCH] Incremental sort  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
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.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] pgbench - allow to store select results intovariables
Next
From: Dmitry Dolgov
Date:
Subject: Re: json(b)_to_tsvector with numeric values