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
