Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XUW1o-00011W-4w for pgsql-performance@arkaria.postgresql.org; Thu, 18 Sep 2014 07:21:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XUW1n-0005OQ-Fl for pgsql-performance@arkaria.postgresql.org; Thu, 18 Sep 2014 07:21:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XUW1m-0005OK-NY for pgsql-performance@postgresql.org; Thu, 18 Sep 2014 07:21:18 +0000 Received: from smtp-outbound-1.vmware.com ([208.91.2.12]) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XUW1e-0007Vx-N4 for pgsql-performance@postgresql.org; Thu, 18 Sep 2014 07:21:17 +0000 Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 9949C2AC02; Thu, 18 Sep 2014 00:21:04 -0700 (PDT) Received: from EX13-CAS-009.vmware.com (EX13-CAS-009.vmware.com [10.113.191.61]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 951B34192E; Thu, 18 Sep 2014 00:21:04 -0700 (PDT) Received: from EX13-MBX-024.vmware.com (10.113.191.44) by EX13-MBX-012.vmware.com (10.113.191.32) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 18 Sep 2014 00:20:52 -0700 Received: from [192.168.1.90] (10.113.160.246) by EX13-MBX-024.vmware.com (10.113.191.44) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 18 Sep 2014 00:20:51 -0700 Message-ID: <541A87C9.4030002@vmware.com> Date: Thu, 18 Sep 2014 10:20:41 +0300 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: Alexander Hill , Subject: Re: Aggregating tsqueries References: In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.160.246] X-ClientProxiedBy: EX13-CAS-013.vmware.com (10.113.191.65) To EX13-MBX-024.vmware.com (10.113.191.44) X-Pg-Spam-Score: -7.6 (-------) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 09/17/2014 07:56 AM, Alexander Hill wrote: > Hello, > > I have a table of tree nodes with a tsquery column. To get a subtree's > tsquery, I need to OR all of its nodes' tsqueries together. > > I defined a custom aggregate using tsquery_or: > > CREATE AGGREGATE tsquery_or_agg (tsquery) > ( > sfunc = tsquery_or, > stype = tsquery > ); > > but I've found that > > tsquery_or_agg(query) > > is about a hundred times slower than this: > > ('(' || string_agg(query::text, ')|(') || ')')::tsquery > > That works perfectly so I'm happy to continue doing it, but I'm curious to > know why the difference is so great and if anything can be done about it? string_agg's state transition function uses a buffer that's expanded as needed. At every step, the next string is appended to the buffer. Your custom aggregate is less efficient, because it constructs a new tsquery object at every step. In every step, a new tsquery object is allocated and the old result and the next source tsquery are copied to it. That's much more expensive. If you're not shy of writing C code, you could write a more efficient version of tsquery_or_agg too, using a similar technique. - Heikki -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance