Re: Big 7.1 open items

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> You can put *user* tables from more than one database into a table space.
>> The restriction is just on *system* tables.

> 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.

I would say that CREATE DATABASE just implicitly creates a new
tablespace that's physically located right under the toplevel data
directory of the installation, no symlink. What's wrong with that?
You need not keep anything except the system tables of the DB there
if you don't want to. In practice, for someone who doesn't need to
worry about tablespaces (because they put the installation on a disk
with enough room for their purposes), the whole thing acts exactly
the same as it does now.

>> 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".

That would imply that the very bottom levels of the system know all
about which tables are system tables and which are not (and, if you
are really going to insist on the "name" part of that, that they
know what name goes with each system-table OID). I'd prefer to avoid
that. The less the smgr knows about the upper levels of the system,
the better.

> Clearly there's no market for renaming system tables or dropping any
> of their columns.

No, but there is a market for compacting indexes on system relations,
and I haven't heard a good proposal for doing index compaction in place.
So we need versioning for system indexes.

>> 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. :-)

Again, WAL should not need to distinguish system and user tables.

And as for the keeping track, the tablespace OID will simply replace the
database OID in the log and in the smgr interfaces. There's no "extra"
cost, except maybe by comparison to a system with neither tablespaces
nor multiple databases.

regards, tom lane