Re: Postgres 7.3.1 poor insert/update/search performance

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: Postgres 7.3.1 poor insert/update/search performance
Дата
Msg-id 1044205301.760.103.camel@tokyo
обсуждение исходный текст
Ответ на Re: Postgres 7.3.1 poor insert/update/search performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Postgres 7.3.1 poor insert/update/search performance  (Curt Sampson <cjs@cynic.net>)
Re: Postgres 7.3.1 poor insert/update/search performance  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-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@samurai.com> || PGP Key ID: DB3C29FC




В списке pgsql-performance по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Postgres 7.3.1 poor insert/update/search performance
Следующее
От: Curt Sampson
Дата:
Сообщение: Re: Postgres 7.3.1 poor insert/update/search performance