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(at)gmx(dot)net 75262 Uppsala
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2000-07-01 15:04:04|
|Subject: Re: config.h (was Re: Misc. consequences of backend memory
|Previous:||From: Peter Eisentraut||Date: 2000-07-01 15:03:17|
|Subject: Re: Changes to handling version numbers internally|