Heikki Linnakangas píše v út 27. 01. 2009 v 21:07 +0200: > Zdenek Kotala wrote: > > Robert Haas píše v út 27. 01. 2009 v 09:45 -0500: > > > >>> 1) Space reservation > >>> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00886.php > >>> http://archives.postgresql.org/pgsql-hackers/2009-01/msg02031.php > >>> > >>> This patch is mandatory for page online conversion and MUST TO be part > >>> of postgreSQL 8.4. if not ... then we will be at the beginning next > >>> year. > >>> > >>> I sent updated version today. > >> I thought we pretty much had agreement that space reservation was not > >> a good solution to anything, although I admit I'm not quite clear on > >> what alternative was being proposed. > > > > Maybe I miss something, but space reservation was selected as a best > > way. Please, Could you point me related mailing thread? > > Space reservation is the way to go, but I remain of the opinion that > trying to predict the future is futile. When we know what we need (= > around the beginning of 8.5 beta), we can backpatch a patch to reserve > the needed amount of space on pages. It has to be dead simple to > consider applying it to a stable branch, but something like "reserve X > bytes for heap pages and Y bytes for b-tree pages if pre_upgrade_mode > GUC is set" should be OK. And we don't want to do anything more > complicated than that anyway before we know what we need.
Set general value for heap or btree is possible but not optimal. For example If you have 5TB table and page layout changes do not affected this table but some small table needs perform a cleanup then 5TB will be processed in general approach, but in optimal variant it will be mark as prepared on upgrade automatically. The patch which I send do this. It is optimal. Only what we don't know is correct calculation, but when 8.5 will be release we will able to create script/procedure which calculate exact space for each relation. Nothing should be backpatched, because script calls something like ALTER TABLE test SET (rs_perpage=4); or UPDATE pg_class SET rs_ perpage=4 where relname='test'; This is a whole idea. thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers