From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Shaun Thomas <shaun(dot)thomas(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andreas Karlsson <andreas(at)proxel(dot)se> |
Subject: | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Date: | 2020-03-31 16:43:14 |
Message-ID: | CAAaqYe_=y8biPXLdXENfVUTn-c8nXOu_NRL2Bwb5gLc+AZ5aHA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 31, 2020 at 12:31 PM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>
> On 2020-Mar-30, James Coleman wrote:
>
> > +/* ----------------
> > + * Instruementation information for IncrementalSort
> > + * ----------------
> > + */
> > +typedef struct IncrementalSortGroupInfo
> > +{
> > + int64 groupCount;
> > + long maxDiskSpaceUsed;
> > + long totalDiskSpaceUsed;
> > + long maxMemorySpaceUsed;
> > + long totalMemorySpaceUsed;
> > + Size sortMethods; /* bitmask of TuplesortMethod */
> > +} IncrementalSortGroupInfo;
>
> There's a typo "Instruementation" in the comment, but I'm more surprised
> that type Size is being used to store a bitmask. It looks weird to me.
> Wouldn't it be more reasonable to use bits32 or some such? (I first
> noticed this in the "sizeof(Size)" code that appears in the explain
> code.)
I just didn't know about bits32; I'll change.
> OTOH, aesthetically it would seem to be better to define these values
> using ones and increasing shifts (1 << 1 and so on), rather than powers
> of two:
>
> > + * TuplesortMethod is used in a bitmask in Increment Sort's shared memory
> > + * instrumentation so needs to have each value be a separate bit.
> > */
> > typedef enum
> > {
> > SORT_TYPE_STILL_IN_PROGRESS = 0,
> > - SORT_TYPE_TOP_N_HEAPSORT,
> > - SORT_TYPE_QUICKSORT,
> > - SORT_TYPE_EXTERNAL_SORT,
> > - SORT_TYPE_EXTERNAL_MERGE
> > + SORT_TYPE_TOP_N_HEAPSORT = 2,
> > + SORT_TYPE_QUICKSORT = 4,
> > + SORT_TYPE_EXTERNAL_SORT = 8,
> > + SORT_TYPE_EXTERNAL_MERGE = 16
> > } TuplesortMethod;
>
> I don't quite understand why you skipped "1". (Also, is the use of zero
> a wise choice?)
The assignment of 0 was already there, and there wasn't a comment to
indicate why. That ends up meaning we wouldn't display "still in
progress" as a type here, which is maybe desirable, but I'm honestly
not sure why it was that way originally. I'm curious if you have any
thoughts on it.
I knew some projects used increasing shifts, but I wasn't sure what
the preference was here. I'll correct.
James
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-31 16:44:53 | Re: Less-silly selectivity for JSONB matching operators |
Previous Message | Tom Lane | 2020-03-31 16:41:50 | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |