Re: index fragmentation on insert-only table with non-unique column

Peter Geoghegan <pg(at)bowt(dot)ie> 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