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