Re: Big 7.1 open items - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Big 7.1 open items
Date
Msg-id 6100.961140887@sss.pgh.pa.us
Whole thread Raw
In response to Re: Big 7.1 open items  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
Chris Bitmead <chrisb@nimrod.itg.telstra.com.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Shared library interdependencies
Next
From: darcy@druid.net (D'Arcy J.M. Cain)
Date:
Subject: Changes to functions and triggers