Message-ID: <53B11110.7070308@realfusio.com>
Date: Mon, 30 Jun 2014 09:26:08 +0200
From: Pujol Mathieu <mathieu.pujol@realfusio.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: GIST optimization to limit calls to operator on sub
 nodes
References: <53A7D547.5080302@realfusio.com>
 <20140629201419.GA63570@hasegeli.local>
In-Reply-To: <20140629201419.GA63570@hasegeli.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


Le 29/06/2014 22:14, Emre Hasegeli a écrit :
> 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.
>
>
Thanks for your reply.
I am not sure to have time to develop inside the framework, but if I try 
I'll let you know my results. In my case the consistent function is 
costly and the number of row important so this optimization could save 
several hundred tests on a single request.

-- 
Mathieu PUJOL
Ingénieur Réalité Virtuelle
REAL FUSIO - 3D Computer Graphics
10, rue des arts - 31000 TOULOUSE - FRANCE
mathieu.pujol@realfusio.com - http://www.realfusio.com


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