The patch has no effect on scans that do updates. The
KillAndReadBuffer routine does not force out a buffer if the dirty
bit is set. So updated pages revert to the current performance
characteristics.
-cktan
GreenPlum, Inc.
On May 10, 2007, at 5:22 AM, Heikki Linnakangas wrote:
Zeugswetter Andreas ADI SD wrote:
In reference to the seq scans roadmap, I have just submitted a
patch that addresses some of the concerns.
The patch does this:
1. for small relation (smaller than 60% of bufferpool), use the
current logic 2. for big relation:
- use a ring buffer in heap scan
- pin first 12 pages when scan starts
- on consumption of every 4-page, read and pin the next 4-page
- invalidate used pages of in the scan so they do not force out
other useful pages
A few comments regarding the effects:
I do not see how this speedup could be caused by readahead, so
what are
the effects ?
I was wondering that as well. We'd really need to test all the
changes separately to see where the improvements are really coming
from.
Also, that patch doesn't address the VACUUM issue at all. And using
a small fixed size ring with scans that do updates can be
devastating. I'm experimenting with different ring sizes for COPY
at the moment. Too small ring leads to a lot of WAL flushes, it's
basically the same problem we have with VACUUM in CVS HEAD.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
