2015-07-23 Robert Haas <robertmh...@gmail.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
