Re: Postgres 7.3.1 poor insert/update/search performance - Mailing list pgsql-performance

From Neil Conway
Subject Re: Postgres 7.3.1 poor insert/update/search performance
Date
Msg-id 1043968734.3123.27.camel@tokyo
Whole thread Raw
In response to Re: Postgres 7.3.1 poor insert/update/search performance  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: Postgres 7.3.1 poor insert/update/search performance
List pgsql-performance
On Wed, 2003-01-22 at 07:05, Andrew Sullivan wrote:
> (As you point out, this caclulation is complicated by the potential to
> waste memory by caching the data twice

If we had a good buffer replacement algorithm (which we currently do
not), ISTM that hot pages retained in PostgreSQL's buffer cache would
never get loaded from the OS's IO cache, thus causing those pages to
eventually be evicted from the OS's cache. So the "cache the data twice"
problem doesn't apply in all circumstances.

> Some systems, like Solaris, allow you to turn off the
> disk cache, so the problem may not be one you face.)

I think it would be interesting to investigate disabling the OS' cache
for all relation I/O (i.e. heap files, index files). That way we could
both improve performance (by moving all the caching into PostgreSQL's
domain, where there is more room for optimization), as well as make
configuration simpler: in an ideal world, it would remove the need to
consider the OS' caching when configuring the amount of shared memory to
allocate to PostgreSQL.

Can this be done using O_DIRECT? If so, is it portable?

BTW, if anyone has any information on actually *using* O_DIRECT, I'd be
interested in it. I tried to quickly hack PostgreSQL to use it, without
success...

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




pgsql-performance by date:

Previous
From: "Chad Thompson"
Date:
Subject: Re: One large v. many small
Next
From: Curt Sampson
Date:
Subject: Re: Postgres 7.3.1 poor insert/update/search performance