"Fabiana Prabhakar" <ffp206@Lehigh.EDU> writes:
> I noticed that version 8.3 has a feature "L2 Cache Scan Protection" that is
> described in the website as "New code optimizations prevent thrashing CPU
> caches which slows concurrent queries".
>
> It would be really helpful for me if I could have some more information
> about this feature, especially if there is any publication that explains it
> in details.
It's probably not terribly interesting to you. It's basically fixing the way
PostgreSQL managed its own memory.
Postgres manages a pool of buffers in shared memory which it uses to store
pages of the database. It uses a clock sweep algorithm to pick buffers which
haven't been used recently when it has to read in a new buffer.
Previously PostgreSQL was using its normal algorithm for all reads. This
optimization made it use a different strategy when it's doing a sequential
scan of a large table. Instead it picks a small number (32 iirc) of buffers
and reuse them over and over again. If a buffer isn't found in the cache it
uses the next buffer from its small pool.
This was measurably faster, possibly due to improved L2 cache efficiency, and
also should spoil the cache less for other backends.
You could look at these two threads for some more information:
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00115.php
http://archives.postgresql.org/pgsql-hackers/2007-05/msg00361.php
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!