Re: OK, OK, Hiroshi's right: use a seperately-generated filename

Peter Eisentraut <peter_e@gmx.net> writes:
> Somehow table spaces need to be catalogued.

Sure.  Undoubtedly there'll be a pg_tablespace table somewhere.  However,
I don't think it's a good idea to have to consult pg_tablespace to find
out where a table actually is --- I think the pathname (or smgr access
token as Ross would call it ;-)) ought to be determinable from just the
pg_class entry.

It would probably be best to expend an additional 4 bytes per pg_class
entry to record the OID of the table's tablespace, just so you could do
joins easily without having to do string matching (and assume an
uncomfortable amount about the format of the pathname).  Having the
pathname in the pg_class entry too represents some denormalization,
but I think it's the safest way.

> For example, before long people will want to
> * Query what tables are in what space (without using string operations)
> * Rename table spaces
> * Assign attributes of some sort to table spaces (permissions, etc.)
> * Use table space names with more than 15 characters. :)

Tablespaces can have logical names stored in pg_tablespace; they just
can't contribute more than a dozen or so characters to file pathnames
under the implementation I'm proposing.  That doesn't seem too
unreasonable; the pathname part can be some sort of abbreviated name.
The alternative is to enlarge smgr access tokens to something like 64
bytes.  I'd rather keep them as compact as we can, since we're going to
need to store them in places like the bufmgr's shared-buffer headers
(remember the blind write problem).

> Then, why are all nth segments of tables in one directory in that
> proposal?

It's better than *all* segments of tables in one directory, which is
what you get if the segment number is just a component of a flat file
name.  We have to have a better answer than that for people who need
to cope with tables bigger than a disk.  Perhaps someone can think of a
better answer than subdirectory-per-segment-number, but I think that
will work well enough; and it doesn't add any complexity for file
access.

> Also, you said before that an old relname (after rename) is worse than
> none at all. I couldn't agree more.

I'm not the one who wants relnames in the physical names ;-).  However,
this implementation mechanism will support either policy choice ---
original relname in the filename, or just a numeric ID for the filename
--- and that seems like a good sign to me.

> Why not use OID.[SEGMENT.]VERSION for the physical relname (different
> order possible)?

Doesn't give you a manageable way to split segments across different
disks.
        regards, tom lane