Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
От | eisentrp@csis.gvsu.edu |
---|---|
Тема | Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Дата | |
Msg-id | Pine.LNX.4.21.0007070911430.12287-100000@eos05.csis.gvsu.edu обсуждение исходный текст |
Ответ на | Re: [SQL] Re: [GENERAL] lztext and compression ratios... (JanWieck@t-online.de (Jan Wieck)) |
Ответы |
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios...
Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios... |
Список | pgsql-hackers |
Maybe you just want to use zlib. Let other guys hammer out the details. On Thu, 6 Jul 2000, Jan Wieck wrote: > While writing it I noticed that the algorithm is really > expensive for big items. The history lookup table allocated > is 8 times (on 32 bit architectures) the size of the input. > So if you want to have 1MB compressed, it'll allocate 8MB for > the history. It hit me when I was hunting a bug in the > toaster earlier today. Doing an update to a toasted item of > 5MB, resulting in a new value of 10MB, the backend blew up to > 290MB of virtual memory - oh boy. I definitely need to make > that smarter. > > When I wrote it I never thought about items that big. It was > before we had the idea of TOAST. > > This all might open another discussion I'll start in a > separate thread. > > > Jan > > -- > > #======================================================================# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #================================================== JanWieck@Yahoo.com # > > > -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: