Re: OK, OK, Hiroshi's right: use a seperately-generated filename
От | Peter Eisentraut |
---|---|
Тема | Re: OK, OK, Hiroshi's right: use a seperately-generated filename |
Дата | |
Msg-id | Pine.LNX.4.21.0006181657280.562-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: OK, OK, Hiroshi's right: use a seperately-generated filename (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: OK, OK, Hiroshi's right: use a seperately-generatedfilename
|
Список | 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 по дате отправления: