Re: POC, WIP: OR-clause support for indexes - Mailing list pgsql-hackers

From jian he
Subject Re: POC, WIP: OR-clause support for indexes
Date
Msg-id CACJufxG=wB6qLbOAWaYEQHccN+qi=6-pw7zKVWZ53ZiDZNRTRA@mail.gmail.com
Whole thread Raw
In response to Re: POC, WIP: OR-clause support for indexes  (jian he <jian.universality@gmail.com>)
Responses Re: POC, WIP: OR-clause support for indexes
List pgsql-hackers
+/*
+ * Hash function that's compatible with guc_name_compare
+ */
+static uint32
+orclause_hash(const void *data, Size keysize)
+{
+ OrClauseGroupKey   *key = (OrClauseGroupKey *) data;
+ uint64 hash;
+
+ (void) JumbleExpr(key->expr, &hash);
+ hash += ((uint64) key->opno + (uint64) key->exprtype) % UINT64_MAX;
+ return hash;
+}

looks strange. `hash` is uint64, but here you return uint32.

based on my understanding of
https://www.postgresql.org/docs/current/xoper-optimization.html#XOPER-COMMUTATOR
I think you need move commutator check right after the `if
(get_op_rettype(opno) != BOOLOID)` branch

+ opno = ((OpExpr *) orqual)->opno;
+ if (get_op_rettype(opno) != BOOLOID)
+ {
+ /* Only operator returning boolean suits OR -> ANY transformation */
+ or_list = lappend(or_list, orqual);
+ continue;
+ }

select  po.oprname,po.oprkind,po.oprcanhash,po.oprleft::regtype,po.oprright,po.oprresult,
po1.oprname
from    pg_operator po join pg_operator po1
on      po.oprcom = po1.oid
where   po.oprresult = 16;

I am wondering, are all these types as long as the return type is bool
suitable for this transformation?



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Parallelize correlated subqueries that execute within each worker
Next
From: James Coleman
Date:
Subject: Re: Parallelize correlated subqueries that execute within each worker