From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-16 07:34:47 |
Message-ID: | 6100.961140887@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> Tom Lane wrote:
>> I don't see a lot of value in that. Better to do something like
>> tablespaces:
>>
>> <dbroot>/<oidoftablespace>/<oidofobject>
> What is the benefit of having oidoftablespace in the directory path?
> Isn't tablespace an idea so you can store it somewhere completely
> different?
> Or is there some symlink idea or something?
Exactly --- I'm assuming that the tablespace "directory" is likely
to be a symlink to some other mounted volume. The point here is
to keep the low-level file access routines from having to know very
much about tablespaces or file organization. In the above proposal,
all they need to know is the relation's OID and the name (or OID)
of the tablespace the relation's assigned to; then they can form
a valid path using a hardwired rule. There's still plenty of
flexibility of organization, but it's not necessary to know that
where the rubber meets the road (eg, when you're down inside mdblindwrt
trying to dump a dirty buffer to disk with no spare resources to find
out anything about the relation the page belongs to...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-06-16 12:42:12 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-16 07:15:53 | Re: Shared library interdependencies |
From | Date | Subject | |
---|---|---|---|
Next Message | Giles Lean | 2000-06-16 09:28:17 | Re: Re: [PORTS] Locale bug |
Previous Message | Hiroshi Inoue | 2000-06-16 07:03:06 | RE: Big 7.1 open items |