Skip site navigation (1) Skip section navigation (2)

Re: seq scan cache vs. index cache smackdown

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: seq scan cache vs. index cache smackdown
Date: 2005-02-15 18:03:53
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A7621@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-performance
Josh Berkus wrote:
> Now you can see why other DBMSs don't use the OS disk cache.  There's
> other
> issues as well; for example, as long as we use the OS disk cache, we
can't
> eliminate checkpoint spikes, at least on Linux.  No matter what we do
with
> the bgwriter, fsyncing the OS disk cache causes heavy system activity.

MS SQL server uses the O/S disk cache...the database is very tightly
integrated with the O/S.  Write performance is one of the few things SQL
server can do better than most other databases despite running on a
mid-grade kernel and a low-grade filesystem...what does that say?
ReadFileScatter() and ReadFileGather() were added to the win32 API
specifically for SQL server...this is somewhat analogous to transaction
based writing such as in Reisfer4.  I'm not arguing ms sql server is
better in any way, IIRC they are still using table locks (!).  

> > It seems inevitable that Postgres will eventually eliminate that
> redundant
> > layer of buffering. Since mmap is not workable, that means using
> O_DIRECT
> > to read table and index data.

IMO, The O_DIRECT argument makes assumptions about storage and o/s
technology that are moving targets.  Not sure about mmap().

Merlin

pgsql-performance by date

Next:From: Greg StarkDate: 2005-02-15 18:39:46
Subject: Re: seq scan cache vs. index cache smackdown
Previous:From: Tom LaneDate: 2005-02-15 17:55:19
Subject: Re: seq scan cache vs. index cache smackdown

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group