Peter Geoghegan <pg@xxxxxxx> writes: > The basic problem is that the B-Tree code doesn't maintain this > property. However, B-Tree index builds will create an index that > initially has this property, because the tuplesort.c code happens to > sort index tuples with a CTID tie-breaker. Yeah. I wonder what would happen if we used the same rule for index insertions. It would likely make insertions more expensive, but maybe not by much. The existing "randomization" rule for where to insert new items in a run of identical index entries would go away, because the insertion point would become deterministic. I am not sure if that's good or bad for insertion performance, but it would likely help for scan performance. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
