Why we are going to have to go DirectIO

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Why we are going to have to go DirectIO
Дата
Msg-id 529E267F.4050700@agliodbs.com
обсуждение исходный текст
Ответы Re: Why we are going to have to go DirectIO  (Robert Haas <robertmhaas@gmail.com>)
Re: Why we are going to have to go DirectIO  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Why we are going to have to go DirectIO  (Jonathan Corbet <corbet@lwn.net>)
Re: Why we are going to have to go DirectIO  (Andres Freund <andres@2ndquadrant.com>)
Re: Why we are going to have to go DirectIO  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
All,

https://lkml.org/lkml/2013/11/24/133

What this means for us:

http://citusdata.com/blog/72-linux-memory-manager-and-your-big-data

It seems clear that Kernel.org, since 2.6, has been in the business of
pushing major, hackish, changes to the IO stack without testing them or
even thinking too hard about what the side-effects might be.  This is
perhaps unsurprising given that two of the largest sponsors of the
Kernel -- who, incidentally, do 100% of the performance testing -- don't
use the IO stack.

This says to me that Linux will clearly be an undependable platform in
the future with the potential to destroy PostgreSQL performance without
warning, leaving us scrambling for workarounds.  Too bad the
alternatives are so unpopular.

I don't know where we'll get the resources to implement our own storage,
but it's looking like we don't have a choice.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Extension Templates S03E11
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Time-Delayed Standbys