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

From Bruce Momjian
Subject Re: Postgres 7.3.1 poor insert/update/search performance
Date
Msg-id 200302021039.h12Adah03315@candle.pha.pa.us
Whole thread Raw
In response to Re: Postgres 7.3.1 poor insert/update/search performance  (Curt Sampson <cjs@cynic.net>)
Responses Re: Postgres 7.3.1 poor insert/update/search performance  (Neil Conway <neilc@samurai.com>)
List pgsql-performance
Curt Sampson wrote:
> > > 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)...
>
> I'm not so sure that there is that all much more room for optimization.
> But take a look at what Solaris and FFS do now, and consider how much
> work it would be to rewrite it, and then see if you even want to do that
> before adding stuff to improve performance.

We need free-behind for large sequential scans, like Solaris has.  Do we
have LRU-2 or LRU-K now?

> > If so, is it portable?
>
> O_DIRECT is not all that portable, I don't think. Certainly not as
> portable as mmap.

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.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: One large v. many small
Next
From: Neil Conway
Date:
Subject: Re: Postgres 7.3.1 poor insert/update/search performance