On Wed, Jul 30, 2014 at 3:04 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
