Peter Eisentraut wrote:
> Tom Lane writes:
>
> > > Also, is the new relfilenode somehow guaranteed to
> > > not be assigned to another relation (pg_class tuple, I think)?
> >
> > I've been wondering about that myself. We might have to add a unique
> > index on pg_class.relfilenode to ensure this; otherwise, after OID
> > wraparound there would be no guarantees.
>
> I've never been happy with the current setup. It's much too tempting to
> think file name = OID, both in the backend code and by external onlookers,
> especially since it's currently rare/impossible(?) for them to be
> different.
Yea, only reindex and cluster change them. Problem is we already have
oid as a nice unique number ready for use. I don't see a huge advantage
of improving it.
> It would be a lot clearer if relfilenode were replaced by an integer
> version, starting at 0, and the heap files were named "OID_VERSION".
Problem there is that we can't have relfilenode as an int unless we take
the table oid and sequence number and merge them on the fly in the
backend. Would be nice for admins, though, so the oid would be there.
I thought WAL liked the relfilenode as a single number.
> (In related news, how about filling up the oid/relfilenode numbers with
> zeros on the left, so a directory listing would reflect the numerical
> order?)
Problem there is that we increase the size of much of the directory
lookups. Not sure if it is worth worrying about.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026