> ... But I think it's critical to keep
> the low-level file access protocol simple and reliable, which really
> means minimizing the amount of information the backend needs to know
> to figure out which file to write a page in. With something like the
> above you only need to know the tablespace name (or more likely OID),
> the relation OID (+name or not, depending on outcome of other
> argument), and the offset in the table. No worse than now from the
> software's point of view.
> Comments?
I'm probably missing the context a bit, but imho we should try hard to
stay away from symlinks as the general solution for anything.
Sorry for being behind here, but to make sure I'm on the right page:
o tablespaces decouple storage from logical tables
o a database lives in a default tablespace, unless specified
o by default, a table will live in the default tablespace
o (eventually) a table can be split across tablespaces
Some thoughts:
o the ability to split single tables across disks was essential for
scalability when disks were small. But with RAID, NAS, etc etc isn't
that a smaller issue now?
o "tablespaces" would implement our less-developed "with location"
feature, right? Splitting databases, whole indices and whole tables
across storage is the biggest win for this work since more users will
use the feature.
o location information needs to travel with individual tables anyway.