Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... - Mailing list pgsql-hackers

From JanWieck@t-online.de (Jan Wieck)
Subject Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Date
Msg-id 200007071947.VAA26359@hot.jw.home
Whole thread Raw
In response to Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (eisentrp@csis.gvsu.edu)
Responses Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (Peter Eisentraut <peter_e@gmx.net>)
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...  (Philip Warner <pjw@rhyme.com.au>)
List 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 by date:

Previous
From: "Darren King"
Date:
Subject: RE: Lessons learned on how to build 7.0.2 on AIX 4.x
Next
From: Tom Lane
Date:
Subject: Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...