Re: GIST optimization to limit calls to operator on sub nodes
От | Tom Lane |
---|---|
Тема | Re: GIST optimization to limit calls to operator on sub nodes |
Дата | |
Msg-id | 4113.1404073822@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GIST optimization to limit calls to operator on sub nodes (Emre Hasegeli <emre@hasegeli.com>) |
Ответы |
Re: GIST optimization to limit calls to operator on sub
nodes
|
Список | 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 по дате отправления: