Re: index fragmentation on insert-only table with non-unique column - Mailing list pgsql-performance

From Tom Lane
Subject Re: index fragmentation on insert-only table with non-unique column
Date
Msg-id 4117.1464151388@sss.pgh.pa.us
Whole thread Raw
In response to Re: index fragmentation on insert-only table with non-unique column  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: index fragmentation on insert-only table with non-unique column  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-performance
Peter Geoghegan <pg@bowt.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


pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: index fragmentation on insert-only table with non-unique column
Next
From: Peter Geoghegan
Date:
Subject: Re: index fragmentation on insert-only table with non-unique column