Re: How Postgresql Compares For Query And Load Operations - Mailing list pgsql-general

From Tom Lane
Subject Re: How Postgresql Compares For Query And Load Operations
Date
Msg-id 24165.995563481@sss.pgh.pa.us
Whole thread Raw
In response to Re: How Postgresql Compares For Query And Load Operations  (Mark kirkwood <markir@slingshot.co.nz>)
Responses Re: How Postgresql Compares For Query And Load Operations  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: How Postgresql Compares For Query And Load Operations  (Mark kirkwood <markir@slingshot.co.nz>)
List pgsql-general
Mark kirkwood <markir@slingshot.co.nz> writes:
> I tried this query :

> SELECT sum(val) FROM fact0

> for Postgres, Db2 and Oracle. The results were

> Postgres    2m25s
> Db2        40s
> Oracle    50s

> This seems to be the likely culprit. I suspect that the "many
> block/page read at once" type optimzations (prefetch for Db2 and mutli
> block read for Oracle) mean that table sequential scans are faster for
> these guys than Postgres.

Hm.  The theory about simple sequential reads is that we expect the
kernel to optimize the disk access, since it'll recognize that we are
doing sequential access to the table file and do read-aheads.  Or that's
the theory, anyway.

I am not convinced that inefficient I/O is the story here.  We could be
paying the price of our very generalized implementation of aggregates.
It would be interesting to know how much CPU time was chewed up by each
DB during the SELECT sum().  It'd also be interesting to know just what
datatype is being summed.

            regards, tom lane

pgsql-general by date:

Previous
From: "Howard Williams"
Date:
Subject: RELAX! - or more to the point, how do I temporarily relax a trigger/constraint?
Next
From: Ed Loehr
Date:
Subject: Re: UNION syntax different for 7.1.2