Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-14 Thread daveg
On Tue, Apr 13, 2010 at 03:03:58PM -0400, Tom Lane wrote: > Joachim Wieland writes: > > If we still cannot do this, then what I am asking is: What does the > > project need to be able to at least link against such a compression > > algorithm? > > Well, what we *really* need is a convincing argume

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-14 Thread Bruce Momjian
Dimitri Fontaine wrote: > Tom Lane writes: > > Well, what we *really* need is a convincing argument that it's worth > > taking some risk for. I find that not obvious. You can pipe the output > > of pg_dump into your-choice-of-compressor, for example, and that gets > > you the ability to spread t

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-14 Thread Dimitri Fontaine
Tom Lane writes: > Well, what we *really* need is a convincing argument that it's worth > taking some risk for. I find that not obvious. You can pipe the output > of pg_dump into your-choice-of-compressor, for example, and that gets > you the ability to spread the work across multiple CPUs in ad

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-14 Thread Stefan Kaltenbrunner
Tom Lane wrote: Joachim Wieland writes: If we still cannot do this, then what I am asking is: What does the project need to be able to at least link against such a compression algorithm? Well, what we *really* need is a convincing argument that it's worth taking some risk for. I find that no

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-13 Thread Tom Lane
Joachim Wieland writes: > If we still cannot do this, then what I am asking is: What does the > project need to be able to at least link against such a compression > algorithm? Well, what we *really* need is a convincing argument that it's worth taking some risk for. I find that not obvious. Yo

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-10 Thread Joachim Wieland
On Fri, Apr 9, 2010 at 5:51 AM, Greg Stark wrote: > Linking against as an option isn't nearly as bad since the user > compiling it can choose whether to include the restricted feature or > not. That's what we do with readline. However it's not nearly as > attractive when it restricts what file for

Re: [HACKERS] a faster compression algorithm for pg_dump

2010-04-08 Thread Greg Stark
On Fri, Apr 9, 2010 at 12:17 AM, Joachim Wieland wrote: > One question that I do not yet see answered is, do we risk violating a > patent even if we just link against a compression library, for example > liblzf, without shipping the actual code? > Generally patents are infringed on when the proce

[HACKERS] a faster compression algorithm for pg_dump

2010-04-08 Thread Joachim Wieland
I'd like to revive the discussion about offering another compression algorithm than zlib to at least pg_dump. There has been a previous discussion here: http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php and it ended without any real result. The results so far were: - There ex