Re: More ideas for speeding up sorting - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: More ideas for speeding up sorting
Date
Msg-id CAM3SWZRBNJML7RKQOAxPJmz7nYHavu5itHfJURedJee=JHLsiQ@mail.gmail.com
Whole thread Raw
In response to Re: More ideas for speeding up sorting  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Fri, Sep 9, 2016 at 1:54 PM, Peter Geoghegan <pg@heroku.com> wrote:
>> 2. We could easily categorize incoming tuples as the come in, into those
>> that have a leading NULL, and others. If we kept them in separate arrays, or
>> perhaps grow memtuples from bottom-up for non-NULLs and from top-down for
>> NULLs, we wouldn't need to store, or compare, the 'isnull1' flag at all, in
>> the quicksort.'
>
> We also wouldn't need to use datum1 to store nothing, at least in the
> "state.tuples" (non-datum-pass-by-value) case. Where the leading
> attribute is NULL, we can "discard" it, and sort those tuples
> separately, and return them to caller first or last as required.

Another thing: ApplySortComparator() (but not
ApplySortAbbrevFullComparator()) is now under no obligation to care
about NULL values, since that happens out-of-band for the leading
attribute. (Actually, you'd need to create a new variation for the
leading attribute only, since we reuse ApplySortComparator() for
non-leading attributes, but that might be yet another win that this
leads to.)

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: More ideas for speeding up sorting
Next
From: Tom Lane
Date:
Subject: Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]