Re: [WIP] Reduce alignment requirements on 64-bit systems.
От | Zdenek Kotala |
---|---|
Тема | Re: [WIP] Reduce alignment requirements on 64-bit systems. |
Дата | |
Msg-id | 48EDB4EE.5070705@sun.com обсуждение исходный текст |
Ответ на | Re: [WIP] Reduce alignment requirements on 64-bit systems. ("Ryan Bradetich" <rbradetich@gmail.com>) |
Ответы |
Re: [WIP] Reduce alignment requirements on 64-bit systems.
|
Список | pgsql-hackers |
Ryan Bradetich napsal(a): > Hello Zdenek, Hello Ryan, > > On Wed, Oct 8, 2008 at 10:59 PM, Zdenek Kotala <Zdenek.Kotala@sun.com> wrote: >> Just a quick look. At first point. Your change introduces new page layout >> version. Which is not acceptable from my point of view for 8.4 (it add > > I would like to see this patch (or some variant) go in if possible. > Since the inplace > upgrades a concern to you, is there anything I can do to help with the inplace > upgrades to help offset the disruption this patch causes you? Yaah, wait until 8.5 :-). However, currently there is no clear consensus which upgrade method is best. I hope that It will clear after Prato developers meeting. Until this meeting I cannot say more. >> another complexity to inplace upgrade). And I guest that it maybe works fine >> on 64bits x86 but it will fail on SPARC and other machine which requires >> aligned data. > > Did I miss something? My intention was to keep the data aligned so it > should work > on any platform. The patch checks the user-defined data to see if > any column requires > the double storage type. If the double storage type is required, it > uses the MAXALIGN() > macro which preserves the alignment for 64-bit data types. If no > columns require the > double storage type, then the data will be INTALIGN() which still > preserves the alignment > requirements. I overlooked 'd' test. Your idea seems to me reasonable. Maybe, you could test 'd' alignment only for NOT NULL values. > If I have a complete mis-understanding of this issue, > please explain it > to me and I will either fix it or withdraw the patch. The problem there is add_item which it is used for indexes as well and they has IndexTupleHeader structure. I'm not convenienceabout idea has two different alignment for items on page. I guess another problem is with MAX_TUPLE_CHUNK_SIZE which uses MAXALIGN for computing. It seems to me that toast chunk could waste a space anyway. And of course you should bump page layout version. I also suggest create function/macro to compute hoff and replace code with this function/macro. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
В списке pgsql-hackers по дате отправления: