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 |
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 |