Skip site navigation (1) Skip section navigation (2)

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: pgsql-hackers(at)postgresql(dot)org
Subject: Re: OK, OK, Hiroshi's right: use a seperately-generated filename
Date: 2000-06-17 13:01:53
Message-ID: Pine.LNX.4.21.0006170403000.17284-100000@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane writes:

> 	tablespace/%d/12345_relname

Throwing table spaces and relation names into one pot doesn't excite me
very much. For example, before long people will want to

* Query what tables are in what space (without using string operations)
Consider for example creating a new table and choosing where to put it.

* Rename table spaces

* Assign attributes of some sort to table spaces (permissions, etc.)

* Use table space names with more than 15 characters. :)

Somehow table spaces need to be catalogued. You could still make the
physical file name 'tablespaceoid/rest' without actually having to look up
anything, although that depends on your symlink idea which is still under
discussion.

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

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

Why not use OID.[SEGMENT.]VERSION for the physical relname (different
order possible)? That way you at least have some guaranteed correspondence
between files and tables. Version could probably be an INT2, so you save
some space.


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

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-06-17 13:02:11
Subject: Re: create user and transactions
Previous:From: Peter EisentrautDate: 2000-06-17 13:00:24
Subject: Install modes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group