Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR

Поиск
Список
Период
Сортировка
От John Lumby
Тема Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR
Дата
Msg-id DM6PR06MB556298A6BBD28D5047C1D824A3F10@DM6PR06MB5562.namprd06.prod.outlook.com
обсуждение исходный текст
Ответ на Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-general
> From: Peter Geoghegan <pg@bowt.ie>
> Sent: July 9, 2019 5:15 PM
> Subject: Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR
>
> On Tue, Jul 9, 2019 at 12:29 PM John Lumby <johnlumby@hotmail.com> wrote:
> > I was not thinking of a new command,  just an extension of the existing REINDEX
> > which would apply a fillfactor equal to current average page density,
> > by adding a preliminary step to sample that first.
>
> That would be a very different thing to REINDEX no matter how you
> spelt it, though. REINDEX creates a new index, from scratch, whereas
> you're talking about restructuring what's already there.

No,  no,   I really am talking about an extension to the *existing* REINDEX,
and yes,  yes,  my extended REINDEX *would* still; create a new index from scratch.
The *only* difference is that,  instead of taking the FILLFACTOR it uses from
whatever is set in the index attributes,  it would take it from first calculating
current average page density.  and then build a new index with that fillfactor.

>
> Or, it could be that range scan performance benefitted from reduced fragmentation,
>

Yes,  I think so.

Cheers,  John


В списке pgsql-general по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR
Следующее
От: Julie Nishimura
Дата:
Сообщение: number of concurrent writes that are allowed for database