Re: How Postgresql Compares For Query And Load Operations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark kirkwood <markir(at)slingshot(dot)co(dot)nz>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: How Postgresql Compares For Query And Load Operations
Date: 2001-07-19 17:24:41
Message-ID: 24165.995563481@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mark kirkwood <markir(at)slingshot(dot)co(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ed Loehr 2001-07-19 17:29:42 Re: UNION syntax different for 7.1.2
Previous Message Tom Lane 2001-07-19 17:13:02 Re: VACUUM ANALYZE