Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51862=pgsql-performance-ar@postgresql.org>)
 id 1X1LUc-0001CM-Ou
 for pgsql-performance@arkaria.postgresql.org; Sun, 29 Jun 2014 20:14:31 +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+M51862=pgsql-performance-ar@postgresql.org>)
 id 1X1LUb-000079-QR
 for pgsql-performance@arkaria.postgresql.org; Sun, 29 Jun 2014 20:14:29 +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 <emre@hasegeli.com>) id 1X1LUa-00006v-4i
 for pgsql-performance@postgresql.org; Sun, 29 Jun 2014 20:14:28 +0000
Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <emre@hasegeli.com>) id 1X1LUW-0007U5-1g
 for pgsql-performance@postgresql.org; Sun, 29 Jun 2014 20:14:25 +0000
Received: by mail-we0-f171.google.com with SMTP id q58so7373573wes.30
 for <pgsql-performance@postgresql.org>; Sun, 29 Jun 2014 13:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hasegeli.com;
 s=google;
 h=date:from:to:cc:subject:message-id:references:mime-version
 :content-type:content-disposition:in-reply-to:user-agent;
 bh=RMFzJl4tSyWiUYS1IciqK0i+I2Jwp7OYwYxrXeuyHKk=;
 b=VEuL6L8SS+d/5HUpsnrSGPuWvtqk1XFBzkKBn4iNyd6fuV68L+MRod1I3cfGjxGgXy
 s/KK9TenCoa3UYl2ipwRbcP3brOcHJAea5PxhVGf1sy2c+4qFeC+4QN3fPhJXeIyVwtP
 n2rOSOEwQaT2O9FW1PVyvCFvZls4MWL3hQ7+E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:references
 :mime-version:content-type:content-disposition:in-reply-to
 :user-agent;
 bh=RMFzJl4tSyWiUYS1IciqK0i+I2Jwp7OYwYxrXeuyHKk=;
 b=fK2zNOyi81nhMWG+G31+8kaFwJvd3Pik2Mbmyx+bZLFEwvsSWvA8pHE7i3gIOLaYDK
 nD9wGU0aBjXDyYL7nB7n7eClJL1bqofmUfKgHIQ0iyQ5/L+2xHCHlSZbtXYqkuV0SOHo
 ZpFl17Xht9VL14P1SPCMQDy1KcrEwmOUpCKLt4DZPJrYuVHSX5xiLEzOKVEMFQStSAp/
 bLT+7s+HSMPOyA8CY3qvpvHNo0uiN+hXHd0hrHkpF9nU2flntg/z4h9OxCaRlyD9iTBc
 1/TigXH352OHdo0P3+Pu7B58B3LPtDsH73eyYUY9ErD0yKEp2PxPKuB0SXESkm6cVigJ
 T4AA==
X-Gm-Message-State: 
 ALoCoQnc0z7lfcA3XAnk5fl58Osm2YA26VBx1jL4EUm63QNHZXwpsUn/nzyUklt1UmzN2dig3N/q
X-Received: by 10.180.37.180 with SMTP id z20mr25011623wij.58.1404072860915;
 Sun, 29 Jun 2014 13:14:20 -0700 (PDT)
Received: from hasegeli.local ([24.133.146.176])
 by mx.google.com with ESMTPSA id o3sm23106498wix.15.2014.06.29.13.14.19
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 29 Jun 2014 13:14:20 -0700 (PDT)
Date: Sun, 29 Jun 2014 23:14:19 +0300
From: Emre Hasegeli <emre@hasegeli.com>
To: Pujol Mathieu <mathieu.pujol@realfusio.com>
Cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: GIST optimization to limit calls to operator on sub
 nodes
Message-ID: <20140629201419.GA63570@hasegeli.local>
References: <53A7D547.5080302@realfusio.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <53A7D547.5080302@realfusio.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Pg-Spam-Score: -2.0 (--)
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

Pujol Mathieu <mathieu.pujol@realfusio.com>:
> Hello,
> I already post my question in the General Mailing list, but without
> succeed so I try this one that seems to me more specialized.
> My question is about GIST index.
> I made my own index to handle specific data and operators. It works
> pretty fine but I wonder if it was possible to optimize it.
> When I run my operator on a GIST node (in the method
> gist_range_consistent) it returns "NotConsistent" /
> "MaybeConsistent" / "FullyConsistent".
> NotConsistent -> means that all subnodes could be ignored,
> gist_range_consistent return false
> MaybeConsistent -> means that at least one subnode/leaf will be
> consistent, gist_range_consistent return true
> FullyConsistent -> means that all subnodes/leaves will be
> consistent, gist_range_consistent return true
> 
> So like with the "recheck flag" I would like to know if there is a
> way to notify postgres that it is not necessary to rerun my operator
> on subnodes, to speedup the search.

I do not think it is possible at the moment.  The GiST framework can
be extended to support this use case.  I am not sure about the
speedup.  Most of the consistent functions do not seem very expensive
compared to other operations of the GiST framework.  I would be
happy to test it, if you would implement.


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