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

RE: Big 7.1 open items

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'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>, Peter Eisentraut <peter_e(at)gmx(dot)net>, 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-06-27 01:42:10
Message-ID: 8F4C99C66D04D4118F580090272A7A23018C38@SECTORBASE1 (view raw or flat)
Thread:
Lists: pgsql-hackers
> > We could create /data/databases/DATABASEOID/ and create 
> > soft-links to table-files. This way different tables of
> > the same database could be in different tablespaces.
> > /data/database path would be used in production
> > and /data/tablespace path would be used in recovery.
> 
> Why would you want to do it that way?  Having a different access path
> for recovery than for normal operation strikes me as just asking for
> trouble ;-)

I just think that *databases* (schemas) must be used for *logical* groupping
of tables, not for *physical* one. "Where to store table" is tablespace'
related kind of things!

> The symlinks wouldn't do any good for what Bruce had in mind anyway
> (IIRC, he wanted to get useful per-database numbers from "du").

Imho, ability to put different tables/indices (of the same database)
to different tablespaces (disks) is much more useful then ability to
use du/ls for administration purposes -:)

Also, I think that we *must* go away from OS' driven disk space
allocation anyway. Currently, the way we extend table files breaks WAL
rule (nothing must go to disk untill logged). + we have to move tuples
from end of file to top to shrink relation - not perfect way to reuse
empty space. +... +... +...

Vadim

pgsql-hackers by date

Next:From: Thomas LockhartDate: 2000-06-27 01:58:22
Subject: Re: 'natural join' core dump
Previous:From: Thomas LockhartDate: 2000-06-27 01:26:48
Subject: Re: Makefile for parser

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