Re: Postgres 7.3.1 poor insert/update/search performance

From: Neil Conway <neilc(at)samurai(dot)com>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres 7.3.1 poor insert/update/search performance
Date: 2003-01-30 23:18:54
Message-ID: 1043968734.3123.27.camel@tokyo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)samurai(dot)com> || PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Curt Sampson 2003-01-31 03:54:26 Re: One large v. many small
Previous Message Gregory Wood 2003-01-30 19:48:16 Re: [PERFORM] One large v. many small