Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR - Mailing list pgsql-general

From John Lumby
Subject Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR
Date
Msg-id DM6PR06MB556298A6BBD28D5047C1D824A3F10@DM6PR06MB5562.namprd06.prod.outlook.com
Whole thread Raw
In response to Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR  (Peter Geoghegan <pg@bowt.ie>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR
Next
From: Julie Nishimura
Date:
Subject: number of concurrent writes that are allowed for database