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

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

In response to

Responses

Browse pgsql-hackers by date

  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