Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead

2015-07-23 Robert Haas <robertmhaas(at)gmail(dot)com>:

> I think what you should do is go find out whether the second rationale
> is valid or not.

Knowing how much impact on performance such “non TID ordered” entries
have, would of course be very useful for future patch authors to know.
Especially useful would be to know whether interleaving a small number
of TID ordered streams (as would probably be generated by parallel
scans/processing) would result in an ordering that performs
significantly worse or not. I assume (but cannot prove) that in this
case the OS will understand the read pattern as being multiple streams
and prefetching will work correctly.

> I'm not going to endorse the notion that tuplesort.c will only DTRT if
> it receives tuples in TID order; it cannot be the responsibility of
> the caller of the sort code to ensure that the tuples are sorted.

Except that it will do the right thing (as in correctness), but maybe
result in not the best overall performance possible (for future
queries). I think that it is a typical property of “reasons for
performance to be good” that they rely on a lot of code that is
otherwise independent, to work together the right way.

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?