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

From Peter Eisentraut
Subject Re: Big 7.1 open items
Date
Msg-id Pine.LNX.4.21.0007011653280.13037-100000@localhost.localdomain
Whole thread Raw
In response to Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Big 7.1 open items  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane writes:

> In practice, for someone who doesn't need to worry about tablespaces
> (because they put the installation on a disk with enough room for
> their purposes), the whole thing acts exactly the same as it does now.

But I'd venture the guess that for someone who wants to use tablespaces it
wouldn't work as expected. Table spaces should represent a physical
storage location. Creation of table spaces should be a restricted
operation, possibly more than, but at least differently from, databases.
Eventually, table spaces probably will have attributes, such as
optimization parameters (random_page_cost). This will not work as expected
if you intermix them with the databases.

I'd expect that if I have three disks and 50 databases, then I make three
tablespaces and assign the databases to them. I'll bet lunch that if we
don't do it that way that before long people will come along and ask for
something that does work this way.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: config.h (was Re: Misc. consequences of backend memory management changes)
Next
From: Tom Lane
Date:
Subject: Re: Big 7.1 open items