Re: There's random access and then there's random access

From: "Douglas McNaught" <doug(at)mcnaught(dot)org>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: There's random access and then there's random access
Date: 2007-12-02 13:27:36
Message-ID: 5ded07e00712020527w1adb45d3ke73ffa180a2c2d59@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/2/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> The two interfaces I'm aware of for this are posix_fadvise() and libaio. I've
> run tests with a synthetic benchmark which generates a large file then reads a
> random selection of blocks from within it using either synchronous reads like
> we do now or either of those interfaces. I saw impressive speed gains on a
> machine with only three drives in a raid array. I did this a while ago so I
> don't have the results handy. I'll rerun the tests again and post them.

The issue I've always seen raised with asynchronous I/O is
portability--apparently some platforms PG runs on don't support it (or
not well). AIUI Linux actually still has a fairly crappy
implementation of AIO--glibc starts threads to do the I/O and then
tracks when they finish. Not absolutely horrible, but a nice way to
suddenly have a threaded backend when you're not expecting one.

-Doug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-12-02 13:59:58 Re: 8.3beta3 ERROR: cached plan must not change result type
Previous Message Gregory Stark 2007-12-02 13:17:09 There's random access and then there's random access