Re: index fragmentation on insert-only table with non-unique column
| От | Tom Lane |
|---|---|
| Тема | Re: index fragmentation on insert-only table with non-unique column |
| Дата | |
| Msg-id | 4117.1464151388@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: index fragmentation on insert-only table with non-unique column (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: index fragmentation on insert-only table with
non-unique column
|
| Список | 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 по дате отправления: