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

From Tom Lane
Subject Re: [HACKERS] [PATCH] Incremental sort
Date
Msg-id 17380.1523118226@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Incremental sort  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: [HACKERS] [PATCH] Incremental sort  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
>> 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.

> I think that improvement in cost calculation of sort should be a 
> separate patch, not directly connected to this one. Postpone patches 
> till other part will be ready to get max improvement for postponed ones 
> doesn't seem to me very good, especially if it suggests some improvement 
> right now.

No, you misunderstand the point of my argument.  Without a reasonably
reliable cost model, this patch could easily make performance *worse*
not better for many people, due to choosing incremental-sort plans
where they were really a loss.

If we were at the start of a development cycle and work were being
promised to be done later in the cycle to improve the planning aspect,
I'd be more charitable about it.  But this isn't merely the end of a
cycle, it's the *last day*.  Now is not the time to commit stuff that
needs, or even just might need, follow-on work.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] [PATCH] Incremental sort
Next
From: Tom Lane
Date:
Subject: Re: Removing useless DISTINCT clauses