From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Andrew Sullivan <andrew(at)libertyrms(dot)info>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres 7.3.1 poor insert/update/search performance |
Date: | 2003-02-02 10:39:36 |
Message-ID: | 200302021039.h12Adah03315@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-02-02 17:01:41 | Re: Postgres 7.3.1 poor insert/update/search performance |
Previous Message | Bruce Momjian | 2003-02-02 10:16:00 | Re: One large v. many small |