Re: How Postgresql Compares For Query And Load Operations

From: Patrick Macdonald <patrickm(at)redhat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mark kirkwood <markir(at)slingshot(dot)co(dot)nz>, pgsql-general(at)postgresql(dot)org
Subject: Re: How Postgresql Compares For Query And Load Operations
Date: 2001-07-20 20:11:03
Message-ID: 3B589057.48C6DD60@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> Hm. The theory about simple sequential reads is that we expect the
> >> kernel to optimize the disk access, since it'll recognize that we are
> >> doing sequential access to the table file and do read-aheads. Or that's
> >> the theory, anyway.
>
> > If it is Linux, they turn off read-ahead on the first fseek() and it
> > never gets turned on again, or so I am told. And because we have
> > virtual file descriptors, that table remains open after random access
> > and the readahead bit doesn't get set for the next sequential scan.
>
> Ugh. And even if we hacked the VFD code to close/reopen the file, the
> shared disk buffers might still have some entries for some blocks of
> the file, causing those blocks not to be requested during the seq scan,
> thus disabling read-ahead again.
>
> It sounds like we really ought to try to get this Linux behavior fixed
> to work more like BSD (ie, some reasonably small number of consecutive
> reads turns on read-ahead). Red Hat guys, are you listening?

Hmmm... Bruce mentioned this yesterday while he was up here and he reiterated
his thoughts in a note this morning. The note has been forwarded to the
appropriate people (ie. kernel folks).

Cheers,
Patrick

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2001-07-20 20:33:17 Re: RPM source files should be in CVS (was Re: psql -l)
Previous Message Travis Bauer 2001-07-20 19:57:20 InputStream as parameter not supported