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

On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

> 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.

I like idea of replacing TrickFunctionCall2 with internal function. Do you
think I should post a separate patch for existing GiST code?

------
With best regards,
Alexander Korotkov.