Re: Perfomance Tuning

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