Re: Faster compression, again - Mailing list pgsql-hackers
| From | Huchev |
|---|---|
| Subject | Re: Faster compression, again |
| Date | |
| Msg-id | CAANrMRpQUSJvXkpJRqnjwTO_eUkR5+F5Ps-neNNA428oz2vn2w@mail.gmail.com Whole thread |
| In response to | Re: Faster compression, again (Daniel Farina <daniel@heroku.com>) |
| List | pgsql-hackers |
Well, the patent argument, used like this, looks like a wild card, which can be freely interpreted as a mortal danger for some, and a non-issue for others. A perfect scare-mongerer.
Quite frankly, I don't buy that one implementation is safer because there is "Google backing it". I can't think of any reason why byte-aligned LZ77 algorithm could face any risk. And btw, just look at the number of companies which had to pay protection money to Microsoft or face litigation with Apple because they were using Google's Android. It looks to me that Google is more a magnet for such dangers than a protector.
Regarding test tools : Yes, this is correct, Snappy C has more fuzzer tools provided within the package.
Regarding integration to BTRFS, and therefore into Linux, both implementation look on equal terms. I haven't seen anything which tells that one has more chances than the other being part of Linux 3.5. In fact, maybe both will be integrated at the same time.
However, a little publicized fact is that quite a few people tried both implementation (Snappy C and LZ4), and there were more failures/difficulties reported on Snappy C. It doesn't mean that Snappy C is bad, just more complex to use. It seems that the LZ4 implementation is more straightforward : less dependancies, less risks, less time spent to properly optimize it,
well, in a word, simpler.
View this message in context: Re: Faster compression, again
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Quite frankly, I don't buy that one implementation is safer because there is "Google backing it". I can't think of any reason why byte-aligned LZ77 algorithm could face any risk. And btw, just look at the number of companies which had to pay protection money to Microsoft or face litigation with Apple because they were using Google's Android. It looks to me that Google is more a magnet for such dangers than a protector.
Regarding test tools : Yes, this is correct, Snappy C has more fuzzer tools provided within the package.
Regarding integration to BTRFS, and therefore into Linux, both implementation look on equal terms. I haven't seen anything which tells that one has more chances than the other being part of Linux 3.5. In fact, maybe both will be integrated at the same time.
However, a little publicized fact is that quite a few people tried both implementation (Snappy C and LZ4), and there were more failures/difficulties reported on Snappy C. It doesn't mean that Snappy C is bad, just more complex to use. It seems that the LZ4 implementation is more straightforward : less dependancies, less risks, less time spent to properly optimize it,
well, in a word, simpler.
Le 5 avril 2012 01:11, Daniel Farina-4 [via PostgreSQL] <[hidden email]> a écrit :
--On Tue, Apr 3, 2012 at 7:29 AM, Huchev <[hidden email]> wrote:
> For a C implementation, it could interesting to consider LZ4 algorithm, since
> it is written natively in this language. In contrast, Snappy has been ported
> to C by Andy from the original C++ Google code, which lso translate into
> less extensive usage and tests.
From what I can tell, the C implementation of snappy has more tests
than this LZ4 implementation, including a fuzz tester. It's a
maintained part of Linux as well, and used for btrfs --- this is why
it was ported. The high compression version of LZ4 is apparently
LGPL. And, finally, there is the issue of patents: snappy has several
multi-billion dollar companies that can be held liable (originator
Google, as well as anyone connected to Linux), and to the best of my
knowledge, nobody has been held to extortion yet.
Consider me unconvinced as to this line of argument.
--
fdr
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackersIf you reply to this email, your message will be added to the discussion below:http://postgresql.1045698.n5.nabble.com/Faster-compression-again-tp5565675p5619199.html
View this message in context: Re: Faster compression, again
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
pgsql-hackers by date: