Обсуждение: Re: [PATCHES] CLUSTER not lose indexes
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. 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". (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?) -- Peter Eisentraut peter_e@gmx.net
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
Peter Eisentraut <peter_e@gmx.net> writes:
> 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".
The reason to not do that is that the bufmgr and levels below would now
need to pass around three numbers, not two, to identify physical files.
We already beat this topic to death a year ago, I'm not eager to re-open
it.
regards, tom lane
On Mon, 15 Jul 2002, Bruce Momjian wrote: > > (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. Probably not such a big deal, since most systems will be reading a full block (8K or 16K under *BSD) to load the directory information anyway. Doing it in hex would give you only 8-char filenames, anyway. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
Curt Sampson wrote: > On Mon, 15 Jul 2002, Bruce Momjian wrote: > > > > (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. > > Probably not such a big deal, since most systems will be reading > a full block (8K or 16K under *BSD) to load the directory information > anyway. Doing it in hex would give you only 8-char filenames, anyway. Yes, hex may be interesting as a more compact, consistent format. We need to change the docs so oid2name and queries convert to hex on output. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> (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?)
> Yes, hex may be interesting as a more compact, consistent format. We
> need to change the docs so oid2name and queries convert to hex on
> output.
I don't really see the value-added here. If we had made this decision
before releasing 7.1, I'd not have objected; but at this point we're
talking about breaking oid2name and any similar scripts that people
may have developed, for what's really a *very* marginal gain. Who cares
whether a directory listing reflects numerical order?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> (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?) > > > Yes, hex may be interesting as a more compact, consistent format. We > > need to change the docs so oid2name and queries convert to hex on > > output. > > I don't really see the value-added here. If we had made this decision > before releasing 7.1, I'd not have objected; but at this point we're > talking about breaking oid2name and any similar scripts that people > may have developed, for what's really a *very* marginal gain. Who cares > whether a directory listing reflects numerical order? I don't see the big value either, just brainstorming. -- 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