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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026