Re: Can postgresql be run in memory (like a memory resi

From: Neil Conway <neilc(at)samurai(dot)com>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Can postgresql be run in memory (like a memory resi
Date: 2003-02-25 23:15:53
Message-ID: 1046214953.427.34.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Doug McNaught 2003-02-25 23:22:57 Re: Compilation errors?
Previous Message Hadley Willan 2003-02-25 23:15:48 Why are absolute paths considered a security risk?