Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id EB2E0632975 for ; Wed, 14 Jul 2010 09:55:40 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 02399-05 for ; Wed, 14 Jul 2010 12:55:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 361486328B7 for ; Wed, 14 Jul 2010 09:55:31 -0300 (ADT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OZ1Um-0006UA-HS for pgsql-performance@postgresql.org; Wed, 14 Jul 2010 14:55:28 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 14:55:28 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 14:55:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Ivan Voras Subject: Re: Understanding tsearch2 performance Date: Wed, 14 Jul 2010 14:55:36 +0200 Lines: 16 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201007/216 X-Sequence-Number: 39605 On 07/14/10 14:31, Oleg Bartunov wrote: > Something is not good with statistics, 91 est. vs 8449 actually returned. I don't think the statistics difference is significant - it's actually using the index so it's ok. And I've run vacuum analyze just before starting the query. > Returning 8449 rows could be quite long. You are right, I didn't test this. Issuing a query which returns a smaller result set is much faster. But, offtopic, why would returning 8500 records, each around 100 bytes long so around 8.5 MB, over local unix sockets, be so slow? The machine in question has a sustained memory bendwidth of nearly 10 GB/s. Does PostgreSQL spend much time marshalling the data through the socket stream?