Re: Postgres 7.3.1 poor insert/update/search performance

On Sun, 2003-02-02 at 05:39, Bruce Momjian wrote:
> We need free-behind for large sequential scans, like Solaris has. Do we
> have LRU-2 or LRU-K now?

No.

> As I remember, DIRECT doesn't return until the data hits the disk
> (because there is no OS cache), so if you want to write a page so you
> can reused the buffer, DIRECT would be quite slow.

Why? If there is a finite amount of memory for doing buffering, the data
needs to be written to disk at *some* point, anyway. And if we didn't
use the OS cache, the size of the PostgreSQL shared buffer would be much
larger (I'd think 80% or more of the physical RAM in a typical high-end
machine, for dedicated PostgreSQL usage).

One possible problem would be the fact that it might mean that writing
out dirty pages would become part of some key code paths in PostgreSQL
(rather than assuming that the OS can write out dirty pages in the
background, as it chooses to). But there are lots of ways to work around
this, notably by using a daemon to periodically write out some of the
pages in the background.

Cheers,

Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC