Re: Adjusting index special storage for pg_filedump's convenience - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Adjusting index special storage for pg_filedump's convenience
Date
Msg-id 462336DD.8060001@enterprisedb.com
Whole thread Raw
In response to Re: Adjusting index special storage for pg_filedump's convenience  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Adjusting index special storage for pg_filedump's convenience
Re: Adjusting index special storage for pg_filedump's convenience
List pgsql-hackers
Tom Lane wrote:
> Gavin Sherry <swm@alcove.com.au> writes:
>> On Mon, 9 Apr 2007, Tom Lane wrote:
>>> ... I don't see any way to make it completely bulletproof
>>> without enlarging the special space, which seems an unreasonable price
>>> to pay.  But even one chance in 16K is way better than the current
>>> situation.
> 
>> Sounds like the only workable approach.
> 
> Actually, I realized after writing that that it *is* possible to make it
> bulletproof: all we have to do is make the BTCycleId wrap around at a
> little less than 64K, which adds about one line of code and doesn't
> materially change its reliability.  That leaves a few bitpatterns free
> for IDs of other index types with no chance of collision.  I made hash
> use 0xFF80 and gist 0xFF81; please use 0xFF82 for bitmaps.  (GIN turns
> out not to need a code because its special space is a different size,
> so we can tell it apart anyway.)
> 
> See patch already committed here:
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00125.php

That's a clever trick, but I can't help thinking we really should have 
an explicit field in the page header to indicate what kind of a page it 
is. It would make life simpler for any external tools that want to peek 
into pages, including migration utilities after a release or two. We've 
also been talking about setting hint bits and doing some kind of retail 
vacuuming in bgwriter with HOT. To do that, we need to identify heap 
pages in the bgwriter. While heap pages can currently be identified by 
the fact that they don't have a special area, it feels hackish, and we 
might want to do something like that for index pages too in the future.

We now have a 16-bit pd_flags field in the page header. We could use a 
few bits from that.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: IN with arrays
Next
From: "Ottó Havasvölgyi"
Date:
Subject: Re: Eliminating unnecessary left joins