Skip site navigation (1) Skip section navigation (2)

Re: Prototype: In-place upgrade v02

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Prototype: In-place upgrade v02
Date: 2008-09-05 17:12:35
Message-ID: 48C16883.2040600@sun.com (view raw or flat)
Thread:
Lists: 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


Attachment: upgrade_02.patch.gz
Description: application/x-gzip (60.5 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2008-09-05 17:13:26
Subject: Re: CVS head has broken make
Previous:From: Tom LaneDate: 2008-09-05 17:12:17
Subject: Re: [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group