Re: [HACKERS] [PATCHES] Reduce heap tuple header size
On Tue, 2 Jul 2002 02:16:29 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: I committed the version with no #ifdef's. If we need them, we can add them later, but it is likely we will never need them. My point was, if there is a need to fallback to v7.2 format, it can be done by changing a single line from #undef to #define. IMO the next patch I'm going to submit is a bit more risky. But if everyone else is confident we can make it stable for v7.3, it's fine by me too. Yes. Manfred, keep going. ;-) Can't guarantee to keep the rate. You know, the kids need a bit more attention when they don't go to school :-) Servus Manfred ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Reduce heap tuple header size
Manfred Koizar wrote: On Tue, 2 Jul 2002 02:16:29 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: I committed the version with no #ifdef's. If we need them, we can add them later, but it is likely we will never need them. My point was, if there is a need to fallback to v7.2 format, it can be done by changing a single line from #undef to #define. IMO the next patch I'm going to submit is a bit more risky. But if everyone else is confident we can make it stable for v7.3, it's fine by me too. Yes, with your recent pages, I think we are committed to changing the format for 7.3. Yes. Manfred, keep going. ;-) Can't guarantee to keep the rate. You know, the kids need a bit more attention when they don't go to school :-) Let me send over my kids. Where are you located? Austria? Hmmm... -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] Reduce heap tuple header size
Tom Lane wrote: Manfred Koizar [EMAIL PROTECTED] writes: ... I wonder whether we shouldn't apply this second version (without the configure parts) and put all forthcoming format changes under #ifndef PG72FORMAT. Seems reasonable. I generally dislike #ifdef clutter, but the #ifs would only be around a couple of macro definitions AFAICT, so the readability hit would be minimal. And someone who wanted back-compatibility would be able to have it, whichever way we jump on the decision for 7.3. I committed the version with no #ifdef's. If we need them, we can add them later, but it is likely we will never need them. At the rate Manfred is going, he'll have patches for all the tuple and page header related issues before August anyway ... so my original gripe about wanting to group those changes into a single release will become moot ;-). I certainly have no objection to doing them all in 7.3 instead of 7.4 if we can get it done. Yes. Manfred, keep going. ;-) -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [PATCHES] Reduce heap tuple header size
Curt Sampson wrote: On Fri, 28 Jun 2002, Bruce Momjian wrote: OK, we need to vote on this patch. It reduces the tuple header by 4 bytes (11% decrease). If we apply it, we will not be able to easily use pg_upgrade for 7.3 because the on-disk table format will change. Votes are: 1) Apply it now 2) Wait until August and see if any other table format changes are made. 3) Delay patch until we have other table format changes. I would tend to say apply it now so that we can get more testing of it. OK, I have heard enough votes to add this. If more votes come in while it is in the queue, we can reevaluate. Also, Manfred is working on making the OID field optional, so it seems we may have more format changes coming. Time to focus on any other data format changes we want to be in 7.3. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Reduce heap tuple header size
Manfred Koizar [EMAIL PROTECTED] writes: ... I wonder whether we shouldn't apply this second version (without the configure parts) and put all forthcoming format changes under #ifndef PG72FORMAT. Seems reasonable. I generally dislike #ifdef clutter, but the #ifs would only be around a couple of macro definitions AFAICT, so the readability hit would be minimal. And someone who wanted back-compatibility would be able to have it, whichever way we jump on the decision for 7.3. At the rate Manfred is going, he'll have patches for all the tuple and page header related issues before August anyway ... so my original gripe about wanting to group those changes into a single release will become moot ;-). I certainly have no objection to doing them all in 7.3 instead of 7.4 if we can get it done. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Reduce heap tuple header size
On Fri, 28 Jun 2002, Bruce Momjian wrote: OK, we need to vote on this patch. It reduces the tuple header by 4 bytes (11% decrease). If we apply it, we will not be able to easily use pg_upgrade for 7.3 because the on-disk table format will change. Votes are: 1) Apply it now 2) Wait until August and see if any other table format changes are made. 3) Delay patch until we have other table format changes. I would tend to say apply it now so that we can get more testing of it. It would also be good to see how else we could save space in the header, e.g., by not having an empty OID field when a table is created without OIDs. (That would double the space savings.) I tend to use ID cross reference tables quite a lot, and these tend to have a lot of rows in them. (E.g., group table has group ID; user table has user-id; a group-id + user-id table determines which users are in which groups. In one project a couple of years ago, such a table was 85 million rows.) These types of tables are typically 8 bytes of data and 40 or so bytes of overhead. Ouch! 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])
