Re: How Postgresql Compares For Query And Load Operations

> > 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.

If it is Linux, they turn off read-ahead on the first fseek() and it
never gets turned on again, or so I am told. And because we have
virtual file descriptors, that table remains open after random access
and the readahead bit doesn't get set for the next sequential scan.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026