From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-21 15:28:09 |
Message-ID: | 4448.961601289@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> Well, as y'all have noticed, I think there are strong reasons to use
> environment variables to manage locations, and that symlinks are a
> potential portability and robustness problem.
Reasons? Evidence?
> An additional point which has relevance to this whole discussion:
> In the future we may allow system resource such as tables to carry names
> which use multi-byte encodings. afaik these encodings are not allowed to
> be used for physical file names, and even if they were the utility of
> using standard operating system utilities like ls goes way down.
Good point, although in one sense a string is a string --- as long as
we don't allow embedded nulls in server-side encodings, we could use
anything that Postgres thought was a name in a filename, and the OS
should take it. But if your local ls doesn't show it the way you see
in Postgres, the usefulness of having the tablename in the filename
goes way down.
> istm that from a portability and evolutionary standpoint OID-only file
> names (or at least file names *not* based on relation/class names) is a
> requirement.
No argument from me ;-). I've been looking for compromise positions
but I still think that pure numeric filenames are the cleanest solution.
There's something else that should be taken into account: for WAL, the
log will need to record the table file that each insert/delete/update
operation affects. To do that with the smgr-token-is-a-pathname
approach I was suggesting yesterday, I think you have to record the
database name and pathname in each WAL log entry. That's 64 bytes/log
entry which is a *lot*. If we bit the bullet and restricted ourselves
to numeric filenames then the log would need just four numeric values:
database OID
tablespace OID
relation OID
relation version number
(this set of 4 values would also be an smgr file reference token).
16 bytes/log entry looks much better than 64.
At the moment I can recall the following opinions:
Pure OID filenames: Thomas, Tom, Marc, Peter E.
OID+relname filenames: Bruce
Vadim was in the pure-OID camp a few months ago, but I won't presume
to list him there now since he hasn't been involved in this most
recent round of discussions. I'm not sure where anyone else stands...
but at least in terms of the core group it's pretty clear where the
majority opinion is.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-21 15:39:23 | Re: Big 7.1 open items] |
Previous Message | Thomas Lockhart | 2000-06-21 15:27:36 | Re: Big 7.1 open items |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-06-21 15:45:12 | Re: Big 7.1 open items |
Previous Message | Thomas Lockhart | 2000-06-21 15:27:36 | Re: Big 7.1 open items |