On Thu, Aug 14, 2014 at 11:38 AM, Robert Haas <robertmhaas@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
