[EMAIL PROTECTED] (Josh Berkus) writes:
>> The other advantage (which I hinted to above) with raw disks is being able
>> to optimize queries to take advantage of it.  Informix is multithreaded
>> and it will spawn off multiple "readers" to do say, a seq scan (and merge
>> the results at the end).
> I like this idea.  Has it ever been discussed for PostgreSQL?  Hmmm
> .... we'd need to see some tests demonstrating that this approach
> was still a technical advantage given the improvements in RAID and
> FS technology since Informix was designed.

Ah, but this approach isn't so much an I/O optimization as it is a CPU

If you have some sort of join against a big table, and do a lot of
processing on each component, there might be CPU benefits from the

create table customers(
  id customer_id,  name character varying, other fields
);  --- And we're a phone company with 8 millions of them...

create table customer_status (
  customer_id customer_id,
  status status_code

create table customer_address (
  customer_id customer_id,

And then are doing:

  select c.id, sum(status), address_label(c.id), balance(c.id) from
     customers c, customer_status cs;

We know there's going to be a SEQ SCAN against customers, because
that's the big table.

If I wanted to finish the query as fast as possible, as things stand
now, and had 4 CPUs, I would run 4 concurrent queries, for 4 ranges of

The Really Cool approach would be for PostgreSQL to dole out customers
across four processors, perhaps throwing a page at a time at each CPU,
where each process would quasi-independently build up their respective
result sets.
let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" [name;tld];;
Christopher Browne
(416) 646 3304 x124 (land)

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to