Re: posix_fadvise v22

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: posix_fadvise v22
Дата
Msg-id 603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: contrib/pg_stat_statements 1226
Следующее
От: "Alex Hunsaker"
Дата:
Сообщение: Re: contrib/pg_stat_statements 1226