Re: when the IndexScan reset to the next ScanKey for in operator - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: when the IndexScan reset to the next ScanKey for in operator
Date
Msg-id 20190822.181346.22906291.horikyota.ntt@gmail.com
Whole thread Raw
In response to when the IndexScan reset to the next ScanKey for in operator  (Alex <zhihui.fan1213@gmail.com>)
List pgsql-hackers
Hi,

At Wed, 21 Aug 2019 20:58:47 +0800, Alex <zhihui.fan1213@gmail.com> wrote in
<CAKU4AWoUnnZE5oz71+pPu=xSHQBeDM649NKMuOxfhATWAzx22g@mail.gmail.com>
> postgres=# select * from t2 where a in (1, 100000);
...
> I can see the plan stores the "1 and 100000" information in
> IndexScan->indexqual, which is an SCALARARRAYOPEXPR expression.
...
> suppose the executor  should scan 1 first,  If all the tuples for 1 has
> been scanned,  then **it should be reset to 100000**  and scan again.
>  however I can't find out the code for that.  looks index_rescan is not for
> this.   am I miss something?

Perhaps _bt_advance_array_keys() and btgettuple() would be what
you are seeking for.

>        /* ... otherwise see if we have more array keys to deal with */
>    } while (so->numArrayKeys && _bt_advance_array_keys(scan, dir));


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Make SQL/JSON error code names match SQL standard
Next
From: Heikki Linnakangas
Date:
Subject: Re: Remove page-read callback from XLogReaderState.