Re: [HACKERS] GUC for cleanup indexes threshold. - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] GUC for cleanup indexes threshold.
Date
Msg-id CAD21AoA16xQsBEoDfZ9U1kpP_7o+CnFFVynZShPhu95W3dR=hQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GUC for cleanup indexes threshold.  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: GUC for cleanup indexes threshold.  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On Wed, Mar 15, 2017 at 7:51 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> On Tue, Mar 14, 2017 at 3:10 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>> We already have BTPageOpaqueData.btpo, a union whose contained type
>> varies based on the page being dead. We could just do the same with
>> some other field in that struct, and then store epoch there. Clearly
>> nobody really cares about most data that remains on the page. Index
>> scans just need to be able to land on it to determine that it's dead,
>> and VACUUM needs to be able to determine whether or not there could
>> possibly be such an index scan at the time it considers recycling..
>
> ISTM that we need all of the fields within BTPageOpaqueData even for
> dead pages, actually. The left links and right links still need to be
> sane, and the flag bits are needed. Plus, the field that stores an XID
> already is clearly necessary. Even if they weren't needed, it would
> probably still be a good idea to keep them around for forensic
> purposes. However, the page header field pd_prune_xid is currently
> unused for indexes, and is the same width as CheckPoint.nextXidEpoch
> (the extra thing we might want to store -- the epoch).
>
> Maybe you could store the epoch within that field when B-Tree VACUUM
> deletes a page, and then compare that within _bt_page_recyclable(). It
> would come before the existing XID comparison in that function. One
> nice thing about this idea is that pd_prune_xid will be all-zero for
> index pages from the current format, so there is no need to take
> special care to make sure that databases that have undergone
> pg_upgrade don't break.
>

Thank you for the suggestion!
If we store the poch within union field, I think we will not be able
to use BTPageOpaqueData.btpo.xact at the same time. Since comparing
btpo.xact is still necessary to determine if that page is recyclable
we cannot store the epoch into the same union field. And if we store
it into BTPageOpaqueData, it would break disk compatibility.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: [HACKERS] dblink module printing unnamed connection (with commit acaf7ccb94)
Next
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] ANALYZE command progress checker