On Thu, Aug 14, 2014 at 11:38 AM, Robert Haas <robertmh...@gmail.com> wrote: > Great. BTW, I notice to my chagrin that 'reindex table > some_table_with_an_indexed_text_column' doesn't benefit from this, > apparently because tuplesort_begin_index_btree is used, and it knows > nothing about sortsupport. I have a feeling there's a good reason for > that, but I don't remember what it is; do you?
No, I don't, but I'm pretty sure that's because there is no good reason. I guess the really compelling original sort support functions were most compelling for the onlyKey case. We can't do that with B-Tree (at least not without another qsort() specialization, like qsort_tuple_btree()), because there is additional tie-breaker logic to sort on item pointer within comparetup_index_btree(). I remember arguing that that wasn't necessary, because of course I wanted to make sortsupport as applicable as possible, but I realize in hindsight that I was probably wrong about that. Clearly there are still benefits to be had for cluster and B-Tree tuplesorts. It looks like more or less a simple matter of programming to me. _bt_mkscankey_nodata() tuplesort call sites like tuplesort_begin_index_btree() can be taught to produce an equivalent sortsupport state. I expect that we'll get around to fixing the problem at some point before too long. -- 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
