> > 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
