Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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 

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 Baltimore, MD

In response to


pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group