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

AW: Big 7.1 open items

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Subject: AW: Big 7.1 open items
Date: 2000-06-19 12:09:31
Message-ID: 219F68D65015D011A8E000006F8590C605BA5976@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> OK, to get back to the point here: so in Oracle, tables can't cross
> tablespace boundaries,

This is only true if you don't insert more coins and buy the Partitioning
Option,
or you use those coins to switch to Informix.
 
> but a tablespace itself could span multiple
> disks?

Yes

> 
> Not sure if I like that better or worse than equating a tablespace
> with a directory (so, presumably, all the files within it live on
> one filesystem) and then trying to make tables able to span
> tablespaces.  We will need to do one or the other though, if we want
> to have any significant improvement over the current state of affairs
> for large tables.

You can currently use a union all view and write appropriate rules
for insert, update and delete in Postgresql. This has the only disadvantage,
that Partitions (fragments, table parts) cannot be optimized away,
but we could fix that if we fixed the optimizer to take check constraints
into account (like check  (year = 2000) and select * where year=1999).

Andreas

pgsql-hackers by date

Next:From: Zeugswetter Andreas SBDate: 2000-06-19 12:14:43
Subject: AW: Big 7.1 open items
Previous:From: Zeugswetter Andreas SBDate: 2000-06-19 11:16:14
Subject: AW: Big 7.1 open items

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