Re: Updated posix fadvise patch v19 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Updated posix fadvise patch v19
Date
Msg-id 87myfxhxh1.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Updated posix fadvise patch v19  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: Updated posix fadvise patch v19  ("Robert Haas" <robertmhaas@gmail.com>)
Re: Updated posix fadvise patch v19  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:

> Looking forward to v20.

Here you go!

I addressed all the nitpicks and added comments.

I also stripped out the sequential i/o posix_fadvises. I'm kind of sad to see
them go since it did seem like a nice way to give more info to the OS even if
no OSes today make good use of it. But one thing at a time and this is clearly
a lot more important. Today we're effectively not using raid arrays properly
at all, we're using them like they're single drives.

One thing which is bothering me is that the guc assign hook is throwing an
error if you set effective_io_concurrency when your system's posix_fadvise is
deemed inadequate (either unavailable or from an old version of glibc). I'm
starting to think it shouldn't throw an error, just not set the internal
variable and possible output a warning. We do have some GUC variables which
throw errors if you use them and support isn't compiled in, but I'm not sure
it's such a hot idea even for those.




--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's RemoteDBA services!

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Updated posix fadvise patch v19
Next
From: Zdenek Kotala
Date:
Subject: Re: toast by chunk-end (was Re: PG_PAGE_LAYOUT_VERSION 5 - time for change)