Re: Updated posix fadvise patch v19

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated posix fadvise patch v19
Date: 2008-11-18 15:20:42
Message-ID: 87myfxhxh1.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Robert Haas" <robertmhaas(at)gmail(dot)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.

Attachment Content-Type Size
posix-fadvise-v20.patch.gz application/octet-stream 12.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-11-18 15:24:44 Re: toast by chunk-end (was Re: PG_PAGE_LAYOUT_VERSION 5 - time for change)
Previous Message Peter Eisentraut 2008-11-18 15:11:42 Re: Updated posix fadvise patch v19