Re: SP-GiST for ranges based on 2d-mapping and quad-tree

On 14.06.2012 01:56, Alexander Korotkov wrote:
> Hackers,
>
> attached patch implements quad-tree on ranges. Some performance results in
> comparison with current GiST indexing.

> @@ -788,7 +774,7 @@ range_super_union(TypeCacheEntry *typcache, RangeType * r1, R
> angeType * r2)
> * part of the relcache entry for the index, typically) this essentially
> * eliminates lookup overhead during operations on a GiST range index.
> */
> -static Datum
> +Datum
> TrickFunctionCall2(PGFunction proc, FmgrInfo *flinfo, Datum arg1, Datum arg2)
> {
> FunctionCallInfoData fcinfo;

I don't think we want to expose TrickFunctionCall2(). Not with that
name, anyway. Perhaps we should refactor the functions called this way,
range_adjacent, range_overlaps etc., to have internal counterparts that
can be called without FunctionCall(). Like:

> ***************
> *** 692,697 ****
> --- 692,708 ----
> {
> RangeType *r1 = PG_GETARG_RANGE(0);
> RangeType *r2 = PG_GETARG_RANGE(1);
> +
> + typcache = range_get_typcache(fcinfo, RangeTypeGetOid(r1));
> +
> + PG_RETURN_BOOL(range_adjacent_internal(r1, r2, typcache);
> + }
> +
> + bool
> + range_adjacent_internal(RangeType r1, RangeType r2, TypeCacheEntry *typcache)
> + {
> + RangeType *r1 = PG_GETARG_RANGE(0);
> + RangeType *r2 = PG_GETARG_RANGE(1);
> TypeCacheEntry *typcache;
> RangeBound lower1,
> lower2;

The gist and SP-gist consistent functions could call the internal
function directly.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com