From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: OK, OK, Hiroshi's right: use a seperately-generated filename |
Date: | 2000-06-18 21:24:26 |
Message-ID: | Pine.LNX.4.21.0006181657280.562-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Kirkpatrick | 2000-06-18 22:43:03 | Re: Call for port testing on fmgr changes -- Results! |
Previous Message | Tom Lane | 2000-06-18 16:06:29 | Re: Big 7.1 open items |