From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL reads each 8k block - no larger blocks are used - even on sequential scans |
Date: | 2009-10-03 16:19:09 |
Message-ID: | 407d949e0910030919w79c3a095gc1a2b995d7d2ca8a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Sep 27, 2009 at 11:18 AM, Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:
> On Sun, Sep 27, 2009 at 06:05:51PM +0200, Gerhard Wiesinger wrote:
>> A google research has shown that Gregory Stark already worked on that issue
>> (see references below) but as far as I saw only on bitmap heap scans.
>
> Greg Stark's patches are about giving the IO subsystem enough
> information about where the random accesses will be ending up next.
> This is important, but almost completely independent from the case
> where you know you're doing sequential IO, which is what you seem to be
> talking about.
FWIW I did work to write code to use FADV_SEQUENTIAL and FADV_RANDOM
but couldn't demonstrate any performance improvement. Basically
Postgres was already capable of saturating any raid controller I could
test doing a normal sequential scan with 8k block sizes and no special
read-ahead advice.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-10-03 16:19:49 | Re: How useful is the money datatype? |
Previous Message | Martin Gainty | 2009-10-03 16:14:19 | Re: Procedure for feature requests? |