Re: posix advises ...

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Abhijit Menon-Sen <ams(at)oryx(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Zoltan Boszormenyi <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: posix advises ...
Date: 2008-07-15 05:07:28
Message-ID: Pine.GSO.4.64.0807150045030.11155@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Sat, 12 Jul 2008, Abhijit Menon-Sen wrote:

> At 2008-07-12 00:52:42 +0100, stark(at)enterprisedb(dot)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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2008-07-15 05:09:27 Re: PATCH: CITEXT 2.0 v3
Previous Message Simon Riggs 2008-07-15 04:51:31 Re: [PATCHES] WIP: executor_hook for pg_stat_statements

Browse pgsql-patches by date

  From Date Subject
Next Message ITAGAKI Takahiro 2008-07-15 07:25:46 Re: [PATCHES] WIP: executor_hook for pg_stat_statements
Previous Message Simon Riggs 2008-07-15 04:51:31 Re: [PATCHES] WIP: executor_hook for pg_stat_statements