Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 010726330A6 for ; Sun, 21 Mar 2010 12:50:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 89977-02 for ; Sun, 21 Mar 2010 15:50:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hawking.rebel.net.au (hawking.rebel.net.au [203.20.69.83]) by mail.postgresql.org (Postfix) with ESMTP id E396C6323D4 for ; Sun, 21 Mar 2010 12:50:38 -0300 (ADT) Received: from [192.168.0.8] (ppp118-210-134-12.lns20.adl6.internode.on.net [::ffff:118.210.134.12]) (AUTH: LOGIN davidn, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by hawking.rebel.net.au with esmtp; Mon, 22 Mar 2010 02:19:32 +1030 id 00110356.4BA6400C.00003CA5 Message-ID: <4BA6404A.5040009@davidnewall.com> Date: Mon, 22 Mar 2010 02:20:34 +1030 From: David Newall User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Tom Lane CC: Craig Ringer , pgsql-performance@postgresql.org, robertmhaas@gmail.com, dcrooke@gmail.com Subject: Re: pg_dump far too slow References: <4B9C97E1.40509@davidnewall.com> <24696.1268598111@sss.pgh.pa.us> <4BA61C74.70506@davidnewall.com> <4BA62596.8050604@postnewspapers.com.au> <22117.1269185944@sss.pgh.pa.us> In-Reply-To: <22117.1269185944@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.67 tagged_above=-10 required=5 tests=AWL=-0.930, BAYES_20=-0.74 X-Spam-Level: X-Archive-Number: 201003/259 X-Sequence-Number: 38084 Tom Lane wrote: > I would bet that the reason for the slow throughput is that gzip > is fruitlessly searching for compressible sequences. It won't find many. > Indeed, I didn't expect much reduction in size, but I also didn't expect a four-order of magnitude increase in run-time (i.e. output at 10MB/second going down to 500KB/second), particularly as my estimate was based on gzipping a previously gzipped file. I think it's probably pathological data, as it were. Might even be of interest to gzip's maintainers.