Re: [PATCH] Incremental sort (was: PoC: Partial sort) - Mailing list pgsql-hackers

From James Coleman
Subject Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Date
Msg-id CAAaqYe9XO7ZKrpVkrz2e0ja=eeFCX0Wqpmc7r23R84JU9uCLxQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (James Coleman <jtc331@gmail.com>)
Responses Re: [PATCH] Incremental sort (was: PoC: Partial sort)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 2, 2020 at 8:46 PM James Coleman <jtc331@gmail.com> wrote:
>
> On Thu, Apr 2, 2020 at 8:20 PM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
> > ...
> > 5) Overall, I think the costing is OK. I'm sure we'll find cases that
> > will need improvements, but that's fine. However, we now have
> >
> > - cost_tuplesort (used to be cost_sort)
> > - cost_full_sort
> > - cost_incremental_sort
> > - cost_sort
> >
> > I find it a bit confusing that we have cost_sort and cost_full_sort. Why
> > don't we just keep using the dummy path in label_sort_with_costsize?
> > That seems to be the only external caller outside costsize.c. Then we
> > could either make cost_full_sort static or get rid of it entirely.
>
> This another area of the patch I haven't really modified.

See attached for a cleanup of this; it removed cost_fullsort so
label_sort_with_costsize is back to how it was.

I've directly merged this into the patch series; if you'd like to see
the diff I can send that along.

James

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: WAL usage calculation patch