On 01/13/2014 10:51 AM, Kevin Grittner wrote:
>> How about "don't add major IO behavior changes with no
>> backwards-compatibility switches"? ;-)
>
> I notice, Josh, that you didn't mention the problems many people
> have run into with Transparent Huge Page defrag and with NUMA
> access. Is that because there *are* configuration options that
> allow people to get decent performance once the issue is diagnosed?
> It seems like maybe there could be a better way to give a heads-up
> on hazards in a new kernel to the database world, but I don't know
> quite what that would be. For all I know, it is already available
> if you know where to look.
Well, it was the lack of sysctl options which takes the 2Q change from
"annoyance" to "potential disaster". We can't ever get away from the
possibility that the Postgres use-case might be the minority use-case,
and we might have to use non-default options. It's when those options
aren't present *at all* that we're stuck.
However, I agree that a worthwhile thing to talk about is having some
better channel to notify the Postgres (and other DB) communities about
major changes to IO and Memory management.
Wanna go to Collab?
>> Seriously, one thing I'd like to get out of Collab would be a
>> reasonable regimen for testing database performance on Linux
>> kernels.
>
> ... or perhaps you figure this is what would bring such issues to
> the community's attention before people are bitten in production
> environments?
That, too.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
