Re: Are there plans to add data compression feature to postgresql?

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: Are there plans to add data compression feature to postgresql?
Дата
Msg-id 87zlkkwtac.fsf@dba2.int.libertyrms.com
обсуждение исходный текст
Ответ на Re: Are there plans to add data compression feature to postgresql?  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Are there plans to add data compression feature to postgresql?  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список pgsql-general
scott.marlowe@gmail.com ("Scott Marlowe") writes:
> I assume hardware failure rates are zero, until there is one.  Then I
> restore from a known good backup.  compressed file systems have little
> to do with that.

There's a way that compressed filesystems might *help* with a risk
factor, here...

By reducing the number of disk drives required to hold the data, you
may be reducing the risk of enough of them failing to invalidate the
RAID array.

If a RAID array is involved, where *some* failures may be silently
coped with, I could readily see this *improving* reliability, in most
cases.

This is at least *vaguely* similar to the way that aircraft have moved
from requiring rather large numbers of engines for cross-Atlantic
trips to requiring just 2.

In the distant past, the engines were sufficiently unreliable that you
wanted to have at least 4 in order to be reasonably assured that you
could limp along with at least 2.

With increases in engine reliability, it's now considered preferable
to have *just* 2 engines, as having 4 means doubling the risk of there
being a failure.

Disk drives and jet engines are hardly the same thing, but I suspect
the analogy fits.
--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://linuxfinances.info/info/lisp.html
Why do they put Braille dots on the keypad of the drive-up ATM?

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

Предыдущее
От: aravind chandu
Дата:
Сообщение: Need Help for a query
Следующее
От: Eric Schwarzenbach
Дата:
Сообщение: Re: Wildly erratic query performance