From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
Cc: | Vivek Khera <khera(at)kcilink(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: State of Beta 2 |
Date: | 2003-09-11 21:24:25 |
Message-ID: | 20030911212425.GG32016@perrin.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > I haven't had a chance to sit down and do any exhaustive testing
> > yet and don't think I will for a while. That said, once 7.4 goes
> > gold, I'm going to provide databases/postgresql-devel with a
> > tunable that will allow people to choose what block size they
> > would like (4k, 8K, 16K, 32K, or 64K) when they build the port.
>
> If you do this, you *have* to put in a very very big warning that
> databases created with non-PostgreSQL-standard block sizes may not
> be transferrable to a standard-PostgreSQL install ... that is Tom's
> major problem, is cross-platform/system dump/restores may no work is
> the database schema was designed with a 16k block size in mind ...
Agreed, but if anyone has a table with close to 1600 columns in a
table... is either nuts or knows what they're doing. If someone has
>1600 columns, that is an issue, but isn't one that I think can be
easily fended off without the backend being able to adapt on the fly
to different block sizes, which seems like something that could be
done with a rewrite of some of this code when table spaces are
introduced.
-sc
--
Sean Chittenden
From | Date | Subject | |
---|---|---|---|
Next Message | Edwin Quijada | 2003-09-11 22:53:35 | Function to convert |
Previous Message | Tom Lane | 2003-09-11 20:55:16 | Re: "another command is already in progress" error (fwd) |