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 по дате отправления: