Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
От | JanWieck@t-online.de (Jan Wieck) |
---|---|
Тема | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Дата | |
Msg-id | 200007071947.VAA26359@hot.jw.home обсуждение исходный текст |
Ответ на | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... (eisentrp@csis.gvsu.edu) |
Ответы |
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Список | pgsql-hackers |
eisentrp@csis.gvsu.edu wrote: > Maybe you just want to use zlib. Let other guys hammer out the details. > We cannot assume that zlib is available everywhere. Thus it must be determined during configure and where it isn't,TOAST can only move off values to make tuples fit into blocks. Since decompression of already in memory itemsis alot faster than doing an index scan on the TOAST table, I expect this to make installations without zlib damnedslow. And how should binary distributions like RPM's handle it? I assume that this problem is already on it's way becauseof the integration of zlib into pg_dump. The only way I see is having different RPM's for each possible combination of available helper libs. Or is there another way to work around? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: