Re: seq scan cache vs. index cache smackdown

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Stark <gsstark(at)MIT(dot)EDU>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Aufflick <mark(at)pumptheory(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: seq scan cache vs. index cache smackdown
Date: 2005-02-15 18:39:46
Message-ID: 87k6p93bwt.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


Josh Berkus <josh(at)agliodbs(dot)com> writes:

> Why is mmap not workable? It would require far-reaching changes to our code
> -- certainly -- but I don't think it can be eliminated from consideration.

Fundamentally because there is no facility for being notified by the OS before
a page is written to disk. And there's no way to prevent a page from being
written to disk (mlock just prevents it from being flushed from memory, not
from being synced to disk).

So there's no way to guarantee the WAL will be written before the buffer is
synced to disk.

Maybe it could be done by writing and syncing the WAL independently before the
shared buffer is written to at all, but that would be a completely different
model. And it would locking the shared buffer until the sync is done, and
require a private copy of the shared buffer necessitating more copies than the
double buffering in the first place.

--
greg

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Magnus Hagander 2005-02-15 18:41:26 Re: seq scan cache vs. index cache smackdown
Previous Message Merlin Moncure 2005-02-15 18:03:53 Re: seq scan cache vs. index cache smackdown