Re: GIST optimization to limit calls to operator on sub nodes - Mailing list pgsql-performance

From Tom Lane
Subject Re: GIST optimization to limit calls to operator on sub nodes
Date
Msg-id 4113.1404073822@sss.pgh.pa.us
Whole thread Raw
In response to Re: GIST optimization to limit calls to operator on sub nodes  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: GIST optimization to limit calls to operator on sub nodes
List pgsql-performance
Emre Hasegeli <emre@hasegeli.com> writes:
> Pujol Mathieu <mathieu.pujol@realfusio.com>:
>> 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.

I don't actually understand what's being requested here that the
NotConsistent case doesn't already cover.

            regards, tom lane


pgsql-performance by date:

Previous
From: Emre Hasegeli
Date:
Subject: Re: GIST optimization to limit calls to operator on sub nodes
Next
From: Heikki Linnakangas
Date:
Subject: Re: Postgres Replaying WAL slowly