On Tue, 2003-02-25 at 15:11, Christopher Browne wrote:
> The tables/databases that are frequently accessed should already be
> mostly in memory as a result of the way your OS caches data.
>
> It's not likely that there's anything that you can do "inside
> PostgreSQL" that would be helpful in this regard.
Strictly speaking, there's plenty you could do inside PostgreSQL to
improve caching. Database access patterns tend to be quite different
from other types of I/O workloads, so designing buffer replacement
policies to account for this has been widely shown to offer better
performance than more generic algorithms such as LRU or GClock (for
example, the LRU-K and 2Q algorithms). Furthermore, the database system
itself knows more than the kernel does about the type of workload that
is being executed. For example, this type of knowledge might allow a
database system to avoid the eviction of hot pages from the buffer
during a large sequential scan.
However, PostgreSQL currently does little of that, and just depends on
the kernel to handle most buffering. There are good reasons for that,
though.
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
