Re: Caching by Postgres

From: Gavin Sherry <swm(at)alcove(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PFC <lists(at)boutiquenumerique(dot)com>, William Yu <wyu(at)talisys(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Caching by Postgres
Date: 2005-08-24 05:24:07
Message-ID: Pine.LNX.4.58.0508241510060.5493@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 24 Aug 2005, Tom Lane wrote:

> Gavin Sherry <swm(at)alcove(dot)com(dot)au> writes:
> > A filesystem could, in theory, help us by providing an API which allows us
> > to tell the file system either: the way we'd like it to read ahead, the
> > fact that we don't want it to read ahead or the way we'd like it to cache
> > (or not cache) data. The thing is, most OSes provide interfaces to do this
> > already and we make only little use of them (I'm think of
> > madv_sequential(), madv_random(), POSIX fadvise(), the various flags to
> > open() which AIX, HPUX, Solaris provide).
>
> Yeah ... the main reason we've not spent too much time on that sort of
> stuff is that *it's not portable*. And with all due respect to Hans,
> special tweaks for one filesystem are even less interesting than special
> tweaks for one OS.

Right.

As an aside, it seems to me that if there is merit in all this low level
interaction with the file system (not to mention the other platform
specific microoptimisations which come up regularly on the lists) then the
companies currently producing niche commercial releases of PostgreSQL
should be taking advantage of them: if it increases performance, then
there's a reason to buy as opposed to just downloading the OSS version.

Gavin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeffrey W. Baker 2005-08-24 05:25:21 Re: Read/Write block sizes
Previous Message Guy Thornley 2005-08-24 05:20:23 Re: Read/Write block sizes