Re: [HACKERS] compression in LO and other fields - Mailing list pgsql-hackers

From wieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] compression in LO and other fields
Date
Msg-id m11mSEF-0003kLC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] compression in LO and other fields  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
>
> Jan Wieck wrote:
> >
> >     Of course.
> >
> >     Well, you asked for the rates on the smaller html files only.
> >     78  files,  131  bytes  min, 10000 bytes max, 4582 bytes avg,
> >     357383 bytes total.
> >
> >     gzip -9 outputs 145659 bytes (59.2%)
> >     gzip -1 outputs 155113 bytes (56.6%)
> >     my code outputs 184109 bytes (48.5%)
> >
> >     67 files, 2000 bytes min, 10000 bytes max,  5239  bytes  avg,
> >     351006 bytes total.
> >
> >     gzip -9 outputs 141772 bytes (59.6%)
> >     gzip -1 outputs 151150 bytes (56.9%)
> >     my code outputs 179428 bytes (48.9%)
> >
> >     The  threshold will surely be a tuning parameter of interest.
> >     Another tuning option must be to allow/deny  compression  per
> >     table  at  all.   Then  we  could  have both options, using a
> >     compressing field type to define which portion of a tuple  to
> >     compress, or allow to compress the entire tuples.
>
> The next step would be tweaking the costs for sequential scans vs.
> index scans.
>
> I guess that the indexes would stay uncompressed ?
>
> ------
> Hannu
>


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: RFC: create/alter user extension
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] compression in LO and other fields