From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More ideas for speeding up sorting |
Date: | 2016-09-09 21:01:14 |
Message-ID: | CAM3SWZRBNJML7RKQOAxPJmz7nYHavu5itHfJURedJee=JHLsiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 9, 2016 at 1:54 PM, Peter Geoghegan <pg(at)heroku(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-09 21:08:19 | Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC] |
Previous Message | Peter Geoghegan | 2016-09-09 20:54:06 | Re: More ideas for speeding up sorting |