Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M52495=pgsql-performance-ar@postgresql.org>)
 id 1XtP7y-0008Rb-7S
 for pgsql-performance@arkaria.postgresql.org; Tue, 25 Nov 2014 23:02:34 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M52495=pgsql-performance-ar@postgresql.org>)
 id 1XtP7x-0001qQ-ND
 for pgsql-performance@arkaria.postgresql.org; Tue, 25 Nov 2014 23:02:33 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1XtP7w-0001nz-7W
 for pgsql-performance@postgresql.org; Tue, 25 Nov 2014 23:02:32 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
 by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1XtP7o-0005mG-QN
 for pgsql-performance@postgresql.org; Tue, 25 Nov 2014 23:02:30 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
 by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id sAPN2MEM024182;
 Tue, 25 Nov 2014 18:02:22 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Scott Marlowe <scott.marlowe@gmail.com>
cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
 pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Small performance regression in 9.2 has a big impact
In-reply-to: 
 <CAOR=d=2Pr7mKCMDD-kY9EMRaOZWA51nPL+BQgGvOuwSMGiRGfA@mail.gmail.com>
References: 
 <CAOR=d=3j1U_q-zf8+jUx1hkx8ps+N8pm=EUTqyFdJ5ov=+fawg@mail.gmail.com>
 <5474ED7C.9030403@vmware.com>
 <CAOR=d=2Pr7mKCMDD-kY9EMRaOZWA51nPL+BQgGvOuwSMGiRGfA@mail.gmail.com>
Comments: In-reply-to Scott Marlowe <scott.marlowe@gmail.com>
 message dated "Tue, 25 Nov 2014 15:25:47 -0700"
Date: Tue, 25 Nov 2014 18:02:22 -0500
Message-ID: <24181.1416956542@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Tue, Nov 25, 2014 at 1:58 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> I don't know why this regressed between those versions, but looking at the
>> functions, there's some low-hanging fruit:
>> 
>> 1. tree_ancestor_keys() could use UNION ALL instead of UNION. (I believe
>> duplicates are expected here, although I'm not 100% sure).
>> 
>> 2. tree_ancestor_keys() calculates tree_level($1) every time it recurses.
>> Would be cheaper to calculate once, and pass it as argument.

> Wow that made a huge difference. About a 50% increase across the
> board. Sadly, 9.2 is still way behind 8.4 (see Tom's email)

Switching from UNION to UNION ALL would dodge the varbit hash-opclass
caching issue, I think.  But there's still something else going on.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance