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