On Sun, 2009-09-27 at 18:05 +0200, Gerhard Wiesinger wrote: > So I saw, that even on sequential reads (and also on bitmap heap scan acces) > PostgreSQL uses only 8k blocks. I think that's a major I/O bottleneck. > > A commercial software database vendor solved the problem by reading multiple > continuous blocks by multiple 8k blocks up to a maximum threshold. Output per > 5 > seconds on an equivalent "sequence scan":
Is systemtap counting actual I/Os or just requests to access 8192 blocks once in OS cache? Postgres doesn't read more than one block at a time into its buffer pool, so those numbers of requests look about right. There is belief here that multi-block I/O was introduced prior to OS doing this as a standard mechanism. Linux expands its read ahead window in response to sequential scans and so this seems like something we don't want to do in the database. It's possible this is wrong. Is the table being scanned fairly sizable and was it allocated contiguously? i.e. was it a large table loaded via COPY? I also wonder if more L2 cache effects exist. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
