Re: Multi CPU Queries - Feedback and/or suggestions wanted!

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, Julius Stroffek <Julius(dot)Stroffek(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org, Dano Vojtek <danielkov(at)gmail(dot)com>
Subject: Re: Multi CPU Queries - Feedback and/or suggestions wanted!
Date: 2008-10-24 06:50:45
Message-ID: 49017045.4050600@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jonah H. Harris wrote:
> On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> True, it is a kludge but if it gives us 95% of the benfit with 10% of
>> the code, it is a win.
>
> I'd say, optimistically, maybe 30-45% the benefit over a proper
> multi-block read using O_DIRECT.

Let's try to focus. We're not talking about using O_DIRECT, we're
talking about using asynchronous I/O or posix_fadvise(). And without
more details on what you mean by benefit, under what circumstances, any
numbers like that is just unmeasurable handwaving.

In terms of getting the RAID array busy, in Greg's tests posix_fadvise()
on Linux worked just as well as async I/O works on Solaris. So it
doesn't seem like there's any inherent performance advantage in the
async I/O interface over posix_fadvise() + read(),

There is differences between different OS implementations of the
interfaces. But we're developing software for the future, and for a wide
range of platforms, and I'm sure operating systems will develop as well.
The decision should not be made on what is the fastest interface on a
given operating system in 2008.

Async I/O might have a small potential edge on CPU usage, because less
system calls are needed. However, let me remind you all that we're
talking about how to utilize RAID array to do physical, random, I/O as
fast as possible. IOW, the bottleneck is I/O, by definition. The CPU
efficiency of the kernel interface to initiate the I/O is insignificant,
until we reach a large enough random read throughput to saturate the
CPU, and even then there's probably more significant CPU savings to be
made elsewhere.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2008-10-24 07:54:14 Re: [HACKERS] Hot Standby utility and administrator functions
Previous Message Heikki Linnakangas 2008-10-24 06:32:51 Re: Multi CPU Queries - Feedback and/or suggestions wanted!