Updated posix fadvise patch v19

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Updated posix fadvise patch v19
Дата
Msg-id 87ljw5c0lx.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответы Re: Updated posix fadvise patch v19  ("Robert Haas" <robertmhaas@gmail.com>)
Список pgsql-hackers
Here is an updated posix_fadvise patch against CVS HEAD. It's my first patch
generated using git, yay. I remembered to strip out configure (WHY is that
STILL in CVS!?) and convert it to context diff, but if there's anything else
I've missed just shout.

Changes from before:

1) Based on discussions changed the parameter to effective_io_concurrency and
   modified the documentation discussion to include comments about SSDs and
   experimentation being necessary.

2) standardized all references to "prefetch" from the mixture of same and
   "preread" and "advise". This means the main entry point is now
   PrefetchBuffer().

3) Added run-time check for buggy glibc versions with bad posix_fadvise()
   since it was pointed out that someone could run on a different version of
   glibc than it was compiled on (such as with binary installers). I kept the
   autoconf test though arguably it's redundant now and could be removed.

Also, the previous patch included support for Zoltan's situation using
POSIX_FADV_SEQUENTIAL for bulk sequential scans. I experimented with this and
was not able to find any situation it improved. I've left it in so others can
test and show it's helpful. This bit of code is a bit less polished -- it's
missing documentation for the guc variable and there are some #defines which
are probably in the wrong .h file (and probably should be an enum).

This code is entirely separate from the prefetching code. They happen to both
use posix_fadvise but I don't think they belong in the same abstraction for
Postgres. PrefetchBuffer does just one thing -- prefetches a buffer.
Sequential i/o needs to be set and tracked per-file.

I have not changed the query costing side of things. I'm a bit leery about
making those changes as I fear it will lead me to propose a major reworking of
these parameters and I don't want to go there...



--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

Вложения

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

Предыдущее
От: Zdenek Kotala
Дата:
Сообщение: PG_PAGE_LAYOUT_VERSION 5 - time for change
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: User defined I/O conversion casts