Re: OK, OK, Hiroshi's right: use a seperately-generated filename - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: OK, OK, Hiroshi's right: use a seperately-generated filename
Date
Msg-id Pine.LNX.4.21.0006181657280.562-100000@localhost.localdomain
Whole thread Raw
In response to Re: OK, OK, Hiroshi's right: use a seperately-generated filename  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename
List pgsql-hackers
Tom Lane writes:

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

That's why I suggested the table space oid. That would be readily
available from pg_class.


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

Since the abbreviated name is really only used internally it might as well
be the oid. Otherwise you create a weird functional dependency like the
pg_shadow.usesysid field that's just an extra layer of maintenance.


> this implementation mechanism will support either policy choice ---
> original relname in the filename, or just a numeric ID for the
> filename

But when you look at a file name `12345_accounts_recei' you know neither

* whether the table name was really `accounts_recei' or whether the name
was truncated

* whether the table still has that name, whatever it was

* what table this is at all

So in the aggregate you really know less than nothing. :-)


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

Okay, so maybe ${base}/TABLESPACEOID/SEGMENT/RELOID.VERSION.

This doesn't need any catalog lookup outside of pg_class, yet it's still
easy to resolve to human-readable names by simple admin tools (SELECT *
FROM pg_foo WHERE oid = xxx). VERSION would be unique within a conceptual
relation, so you could even see how many times the relation was altered in
major ways (kind of).


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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Big 7.1 open items
Next
From: Ryan Kirkpatrick
Date:
Subject: Re: Call for port testing on fmgr changes -- Results!