Jeff wrote:
> > You raise a good point vis-a-vis the thought of spawning multiple
> > readers; that could conceivably be a useful approach to improve
> > performance for very large queries. If you could "stripe" the tables
> > in some manner so they could be doled out to multiple worker
> > processes, that could indeed provide some benefits. If there are
> > three workers, they might round-robin to grab successive pages from
> > the table to do their work, and then end with a merge step.
>
> The way informix does this is two fold:
> 1. it handles the raw disks, it knows where table data is
> 2. it can "partition" tables in a number of ways: round robin,
> concatination or expression (Expression is nifty, allows you to use a
> basic "where" clause to decide where to put data. ie
> create table foo (
> a int,
> b int,
> c int ) fragment on c > 0 and c < 100 in dbspace1, c > 100 c < 200 in
> dbspace 2;
>
> that kind of thing.
> and yeah, I would not expect to see it for a long time.. Without threading
> it would be rather difficult to implement.. but who knows what the future
> will bring us.
The big question is whether the added complexity is worth it. I know
Informix 5 was faster than Informix 7 on single CPU machines for quite a
while. It might still be true.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073