On Fri, Sep 9, 2016 at 1:54 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
