Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: posix_fadvise v22
Date
Msg-id 603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com
Whole thread Raw
In response to Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: posix_fadvise v22  (Greg Stark <greg.stark@enterprisedb.com>)
Re: posix_fadvise v22  (Greg Smith <gsmith@gregsmith.com>)
Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 1, 2009 at 3:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Robert Haas" <robertmhaas@gmail.com> writes:
>> Am I correct in thinking that the only thing we're really checking for
>> here is whether a trivial posix_fadvise() call returns success?  If
>> so, is this test really worth doing?
>
> Runtime tests performed during configure are generally a bad idea to
> start with --- it's impossible to do any such thing in a
> cross-compilation scenario, for example.

OK, here's an update of Greg's patch with the runtime configure test
ripped out, some minor documentation tweaks, and a few unnecessary
whitespace diff hunks quashed.  I think this is about ready for
committer review.  The only thing I haven't been able to do is
demonstrate that this change actually produces a performance
improvement.  Either I'm testing the wrong thing, or it just doesn't
provide any benefit on a single-spindle system.  However, I believe
that Greg has previously posted some fairly impressive performance
results, so I'm not sure that my shortcomings in this area should be a
bar to having a committer pick this one up.  If more testing is
needed, it would at least be helpful to have a committer specify what
areas they are concerned about.

...Robert

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: contrib/pg_stat_statements 1226
Next
From: "Alex Hunsaker"
Date:
Subject: Re: contrib/pg_stat_statements 1226