Re: Prototype: In-place upgrade v02
От | Zdenek Kotala |
---|---|
Тема | Re: Prototype: In-place upgrade v02 |
Дата | |
Msg-id | 48C16883.2040600@sun.com обсуждение исходный текст |
Ответ на | Re: Prototype: In-place upgrade (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Prototype: In-place upgrade v02
|
Список | pgsql-hackers |
Heikki Linnakangas napsal(a): > The patch seems to be missing the new htup.c file. I'm sorry. I attached new version which is synchronized with current head. I would like to say more comments as well. 1) The patch contains also changes which was discussed during July commit fest. - PageGetTempPage modification suggested by Tom - another hash.h backward compatible cleanup 2) I add tuplimits.h header file which contains tuple limits for different access method. It is not finished yet, but idea is to keep all limits in one file and easily add limits for different page layout version - for example replace static computing with dynamic based on relation (maxtuplesize could be store in pg_class for each relation). I need this header also because I fallen in a cycle in header dependency. 3) I already sent Page API performance result in http://archives.postgresql.org/pgsql-hackers/2008-08/msg00398.php I replaced call sequence PagetGetItemId, PageGetItemId with PageGetIndexTuple and PageGetHeapTuple function. It is main difference in this patch. PAgeGetHeap Tuple fills t_ver in HeapTuple to identify correct tupleheader version. It would be good to mention that PageAPI (and tuple API) implementation is only prototype without any performance optimization. 4) This patch contains more topics for decision. First is general if this approach is acceptable. Second is about new Page API if we replace all page access with new proposed macros/(inline)function. Third is how to name and where store different data structure version. My idea is use suffix with underscore and page layout version and keep all version in a same header file. 5) I got another idea about usage of page API. I call it "3 in 1". Because all page access will be through New API, it could be use for WAL logging and other WAL recording could be reduced. Replication could be easily added based on page modification. It is just idea for thinking. 6) it is probably all for Friday evening. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
Вложения
В списке pgsql-hackers по дате отправления: