On Thu, Jun 21, 2012 at 11:12 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.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.