Re: How Postgresql Compares For Query And Load Operations

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: How Postgresql Compares For Query And Load Operations
Дата
Msg-id 24165.995563481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: How Postgresql Compares For Query And Load Operations  (Mark kirkwood <markir@slingshot.co.nz>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "Howard Williams"
Дата:
Сообщение: RELAX! - or more to the point, how do I temporarily relax a trigger/constraint?
Следующее
От: Ed Loehr
Дата:
Сообщение: Re: UNION syntax different for 7.1.2