From: Greg Smith <gsmith@gregsmith.com>
To: Abhijit Menon-Sen <ams@oryx.com>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: Zoltan Boszormenyi <zb@cybertec.at>
Cc: pgsql-hackers@postgresql.org
Subject: Re: posix advises ...
Date: Tue, 15 Jul 2008 01:07:28 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0807150045030.11155@westnet.com> (raw)
In-Reply-To: <20080712113432.GA26415@toroid.org>
References: <4826C200.8060807@cybertec.at>
<Pine.GSO.4.64.0805132139250.20823@westnet.com>
<485A3F20.1080907@cybertec.at>
<20080711100215.GA14893@toroid.org>
<87abgo0yid.fsf@oxford.xeocode.com>
<20080712113432.GA26415@toroid.org>
On Sat, 12 Jul 2008, Abhijit Menon-Sen wrote:
> At 2008-07-12 00:52:42 +0100, stark@enterprisedb.com wrote:
>>
>> The later versions of mine had a GUC named effective_spindle_count
>> which I think is nicely abstracted away from the implementation
>> details.
>
> Yes, that does sound much better. (The patch I read had a
> preread_pages_bitmapscan variable instead.)
This patch does need a bit of general care in a couple of areas. The
reviewing game plan I'm working through goes like this:
1) Update the original fadvise test program Greg Stark wrote to be a bit
easier to use for testing general compatibility of this approach. I want
to collect some data from at least two Linux and Solaris systems with
different disk setups.
2) Check out effective_spindle_count and see if it looks like a reasonable
way to tune this feature. If so, will probably need to merge that in to
Zoltan's version of the patch. May need some other cleanup in that patch
set as well--I'm not sure that closed XLOG patch that got pushed into here
as well is really helpful for example.
3) Generate a sequential scan test program aimed to hobble the Linux
kernel in the way Zoltan described as motivation for his work. I'm
working with Jeff Davis this week to try and repurpose some of his
syncronized scan test programs to handle this while we're both in the same
place for a bit.
4) Generate a bitmap scan test program to check the original patch.
5) If the performance results look useful and consistant, then move toward
cleaning up broader compatibility issues like the segfault concerns Zoltan
mentioned.
Going to take a while to work through all that, but performance patches
with platform-specific benefit are always painful like this.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: gsmith@gregsmith.com, ams@oryx.com, stark@enterprisedb.com, zb@cybertec.at, pgsql-hackers@postgresql.org
Subject: Re: posix advises ...
In-Reply-To: <Pine.GSO.4.64.0807150045030.11155@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox