Re: Significantly larger toast tables on 8.4?

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Significantly larger toast tables on 8.4?
Дата
Msg-id b42b73150901050855v42b9ddd1s7166cecdbf1ee665@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Significantly larger toast tables on 8.4?  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Mon, Jan 5, 2009 at 11:45 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Peter Eisentraut escribió:
>> James Mansion wrote:
>>> Peter Eisentraut wrote:
>>>>> c. Are there any well-known pitfalls/objections which would prevent
>>>>> me from
>>>>>    changing the algorithm to something more efficient (read: IO-bound)?
>>>>
>>>> copyright licenses and patents
>>>>
>>> Would it be possible to have a plugin facility?
>>
>> Well, before we consider that, we'd probably want to see proof about the
>>  effectiveness of other compression methods.
>
> I did some measurements months ago, and it was very clear that libz
> compression was a lot tighter than the PGLZ code.

we have seen amazing results with lzo compression...2-3x faster
compression times with only 10-15% less compression:

There are tons of supporting examples online, for example:
http://mail.jabber.org/pipermail/standards/2005-October/008768.html

I think, if the database is automatically compressing things (which,
IMO, it shouldn't), a low cpu overhead algorithm should be favored.

merlin


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Updates of SE-PostgreSQL 8.4devel patches (r1386)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump roles support