Re: WIP: Page space reservation (pgupgrade)

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Page space reservation (pgupgrade)
Date: 2008-11-10 08:21:48
Message-ID: 4917EF1C.8010200@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas napsal(a):

> Let's suppose, for example, that in 8.5 we decide to change some type
> that is presently 16 bits to 32 bits, or 8 bits to 16 bits, etc. This
> will make some tuples bigger, and potentially much bigger, but since
> it presumably won't be a commonly used data-type, most tuples won't
> change at all. However, the worst case scenario for how much free
> space you might need to reserve will be very bad, and therefore a
> mechanism that allows reserving a fixed amount of free space per page
> won't be adequate.

The problem with datatypes is different story. It is should be easy to manage
this problem with keeping the old datatype definition for "old" tables and for
new create new datatype with new OID. You can use ALTER TABLE for converting
data from old type to the new one.

Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Tolley 2008-11-10 08:57:57 Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets
Previous Message Zdenek Kotala 2008-11-10 08:15:13 Re: [WIP] In-place upgrade