Re: There's random access and then there's random access - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: There's random access and then there's random access
Date
Msg-id 87eje5golt.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: There's random access and then there's random access  ("Douglas McNaught" <doug@mcnaught.org>)
List pgsql-hackers
"Douglas McNaught" <doug@mcnaught.org> writes:

> On 12/2/07, Gregory Stark <stark@enterprisedb.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.

In the tests I ran Linux's posix_fadvise worked well and that's the simpler
interface for us to adapt to anyways. On Solaris there was no posix_fadvise
but libaio worked instead.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: 8.3beta3 ERROR: cached plan must not change result type
Next
From: Tom Lane
Date:
Subject: Re: There's random access and then there's random access