Re: Big 7.1 open items

Tom Lane writes:

> You can put *user* tables from more than one database into a table space.
> The restriction is just on *system* tables.

I think my understanding as a user would be that a table space represents
a storage location. If I want to put a table/object/entire database on a
fancy disk somewhere I create a table space for it there. But if I want to
store all my stuff under /usr/local/pgsql/data then I wouldn't expect to
have to create more than one table space. So the table spaces become at
that point affected by the logical hierarchy: I must make sure to have
enough table spaces to have many databases.

More specifically, what would the user interface to this look like?
Clearly there has to be some sort of CREATE TABLESPACE command. Now does
CREATE DATABASE imply a CREATE TABLESPACE? I think not. Do you have to
create a table space before creating each database? I think not.

> We could avoid it along the lines you suggest (name table files like
> DBOID.RELOID.VERSION instead of just RELOID.VERSION) but is it really
> worth it?

I only intended that for pg_class and other bootstrap-sort-of tables,
maybe all system tables. Normal heap files could look like RELOID.VERSION,
whereas system tables would look like "name.DBOID". Clearly there's no
market for renaming system tables or dropping any of their columns. We're
obviously going to have to treat pg_class special anyway.

> Vadim's concerned about every byte that has to go into the WAL log,
> and I think he's got a good point.

True. But if you only do it for the system tables then it might take less
space than keeping track of lots of table spaces that are unneeded. :-)

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden