Re: What does Page Layout version mean? (Was: Re: Reducing NUMERIC size for 8.3)

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>
Subject: Re: What does Page Layout version mean? (Was: Re: Reducing NUMERIC size for 8.3)
Date: 2007-06-28 01:38:58
Message-ID: 200706271838.58498.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> That sounds good, but there are corner cases where it wouldn't work ---
> consider a page containing a single maximum-length tuple.

Certainly any mature upgrade-in-place tool will require a "checker" which you
run first which determines if you have a prohibitive corner case.

Besides, I thought we didn't allow tuples to grow to more than 1/2 page size?
Or am I thinking indexes here?

> In general I don't see us accepting changes that would increase data
> size, but there's at least one troubling exception on the horizon:
> per-column or per-value locale support. Another problem is that a strict
> rule of "no data size increase ever" might forbid acceptance of changes
> that achieve average space savings at the cost of increasing the size of
> some lesser-used cases.

Our attitude at the meeting was "let's burn that bridge when we come to it".
If we can develop a solid in-place upgrade too which will work for 8.1->8.2
and 8.2->8.3, then we've done something worthwhile even if we break it in 8.4
or 8.5. It's possible that we won't implement anything that breaks it for
five years or that someone will invent another solution before then, in which
case we'd feel pretty dumb for having kept it on the drawing board all that
time.

Or to put it another way, the page-grows-on-upgrade problem is hard enough
that it will probably take as much effort as the whole rest of the upgrade
process to solve. So let's tackle one problem at a time.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ITAGAKI Takahiro 2007-06-28 04:19:05 Re: Bgwriter LRU cleaning: we've been going at this all wrong
Previous Message Kenneth Marshall 2007-06-28 01:33:44 Re: todo: Hash index creation