Re: Is a plan for lmza commpression in pg_dump

Поиск
Список
Период
Сортировка
On Sat, Feb 07, 2009 at 02:47:05PM -0500, Bruce Momjian wrote:
> daveg wrote:
> > On Wed, Feb 04, 2009 at 10:23:17PM -0500, Andrew Chernow wrote:
> > > Dann Corbit wrote:
> > > >
> > > >The LZMA SDK is granted to the public domain:
> > > >http://www.7-zip.org/sdk.html
> > > >
> > > 
> > > I played with this but found the SDK extremely confusing and flat out 
> > > horrible. One personal dislike was the unnecessary use of C++; although it 
> > >  was the horrible API that turned me off.  I'm not even sure if I ever got a 
> > > test program working.
> > > 
> > > LZO (http://www.oberhumer.com/opensource/lzo/) is a great algorithm, easy 
> > > API with many variants; my fav is LZO1X-1(15).  Its known for its 
> > > compresison and decompresison speeds ... its blazing fast.  zlib typically 
> > > gets 5-8% more compression.
> > 
> > LZO rocks. I wonder if the lzo developer would consider a license exception
> > so that postgresql could use it?  What would we need?
> 
> The chance of us using anything but one zlib is near zero so please do
> not persue this;  this discussion comes up much too often.

That this comes up "much to often" suggests that there is more than near
zero interest.  Why can only one compression library can be considered?
We use multiple readline implementations, for better or worse.

I think the context here is for pg_dump only and in that context a faster
compression library makes a lot of sense. I'd be happy to prepare a patch
if the license issue can be accomodated. Hence my question, what sort of
licence accomodation would we need to be able to use this library?

-dg

-- 
David Gould       daveg@sonic.net      510 536 1443    510 282 0869
If simplicity worked, the world would be overrun with insects.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: add_path optimization
Следующее
От: Grzegorz Jaskiewicz
Дата:
Сообщение: Re: Is a plan for lmza commpression in pg_dump