when the IndexScan reset to the next ScanKey for in operator
given the following example:
postgres=# create table t2 as select generate_series(1, 100000) as a,
generate_series(1, 100000) as b;
SELECT 100000
postgres=# create index t2_idx on t2(a);
CREATE INDEX
postgres=# set enable_seqscan = 0;
SET
postgres=# select * from t2 where a in (1, 100000);
a | b
--------+--------
1 | 1
100000 | 100000
(2 rows)
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?
thanks
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
On Wed, Aug 21, 2019 at 6:24 AM Alex <zhihui.fan1213@gmail.com> wrote:
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.
You might find my nbtree index scan test patch useful:
/messages/by-id/CAH2-WzmRT_0YbHF05axQb2OiTUQiQAkr0Lznntj8X3KADKZ-5g@mail.gmail.com
--
Peter Geoghegan