Re: [HACKERS] compression in LO and other fields
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] compression in LO and other fields |
Дата | |
Msg-id | m11mSEF-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] compression in LO and other fields (Hannu Krosing <hannu@tm.ee>) |
Список | 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 по дате отправления: