Skip site navigation (1) Skip section navigation (2)

Re: Big 7.1 open items

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jan Wieck <JanWieck(at)yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: Re: Big 7.1 open items
Date: 2000-07-01 15:03:42
Message-ID: Pine.LNX.4.21.0007011653280.13037-100000@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: 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(at)gmx(dot)net                   75262 Uppsala            Sweden

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-07-01 15:04:04
Subject: Re: config.h (was Re: Misc. consequences of backend memory management changes)
Previous:From: Peter EisentrautDate: 2000-07-01 15:03:17
Subject: Re: Changes to handling version numbers internally

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group