On Fri, 27 Feb 2004 [EMAIL PROTECTED] 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
