Re: Big 7.1 open items

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

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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