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

Re: Tablespaces

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: tswan(at)idigx(dot)com
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>,"Alex J(dot) Avriette" <alex(at)posixnap(dot)net>,Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tablespaces
Date: 2004-02-28 00:03:12
Message-ID: Pine.LNX.4.58.0402281052160.29841@linuxworld.com.au (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 27 Feb 2004 tswan(at)idigx(dot)com wrote:

> >
> >> I do not intend to undertake raw disk tablespaces for 7.5. I'd be
> >> interested if anyone could provide some real world benchmarking of file
> >> system vs. raw disk. Postgres benefits a lot from kernel file system
> >> cache
> >> at the moment.
> >
> > Yes, and don't forget that pg also relys on the OS for grouping and
> > sorting the physical writes and doing readahead where appropriate.
> >
> >
>
> Most people I know want tablespaces in order to limit or preallocate the
> disk space used by a table or database in addition to controlling the
> physical location of a table or database.
>
> I know on linux, there is the option of creating an empty file or a
> specific size using dd, mounting it through loopback, formatting it,
> symlinking the appropriate OID/TID (or mounting the lpb device in the
> appropriate directory) and then you control how much space that
> directory/mount point can contain.
>
> Of course, with MVCC you would have to vacuum frequently, as you could
> miss some updates if there weren't enough tuples marked as free.  If there
> were "in-place" updates, the preallocation and limitation much easier, but
> that's not how PG works.

I do not intend to work on such a system for the initial introduction of
table spaces. The problem is, of course, knowing when you're actually out
of space in a table space in any given transaction. Given that WAL is on a
different partition (at least for the moment) the table space will not
have transaction X's data written to it until after transaction X is
finished. And we cannot error out a transaction which is already commited.

The solution is to keep track of free space and error out at some
percentage of free space remaining. But I don't want to complicate
tablespaces too much in 7.5.

Thanks,

Gavin

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2004-02-28 00:47:30
Subject: Re: [HACKERS] Collaboration Tool Proposal
Previous:From: Josh BerkusDate: 2004-02-27 23:31:14
Subject: Re: [pgsql-www] Collaboration Tool Proposal

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