On Wed, Jul 30, 2014 at 3:04 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I feel it should be possible for both the Datum and Heap sort cases to
> use the new optimization (since they can always use sort support)
> wherever they can afford to make that normalization pass (they usually
> can, since copytup* is usually passed through). Eventually, I think
> we'll want to extend sort support to work with btree index builds.
Actually, scratch that; I think it should be possible to have things
like aggregates with a single ORDER BY expression use the
normalization optimization where available (a slightly less specific
statement than the above). I do not in fact think we should make this
work for tuplesort_begin_datum(). The single column case ORDER BY
aggregate happens to use a datum representation within tuplesort,
whereas the multi input column case uses heap tuples (and
tuplesort_begin_heap(), etc).
What I mean is that I think the best way to accomplish what we really
want here is probably to make the single column case artificially do
the same thing as the multi-column case where we know there is a sort
support routine with normalization support. That has to be a superior
approach to jury-rigging tuplesort to differentiate between normalized
keys and an original representation where tuplesort_getdatum() is
consulted. It's a bit ugly that datum sorts will then support sort
support, but only when this new infrastructure is unused. I see no
better way.
Now, to figure out a reasonable way to have nodeAgg.c ask "does this
sort operator have a real sort support function that happens to use
the new normalization capability?" before calling either
tuplesort_begin_heap() or tuplesort_begin_datum()...
--
Peter Geoghegan
