Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
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 [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [PATCHES] CLUSTER not lose indexes
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
