From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | zhihui(dot)fan1213(at)gmail(dot)com |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: when the IndexScan reset to the next ScanKey for in operator |
Date: | 2019-08-22 09:13:46 |
Message-ID: | 20190822.181346.22906291.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
At Wed, 21 Aug 2019 20:58:47 +0800, Alex <zhihui(dot)fan1213(at)gmail(dot)com> wrote in <CAKU4AWoUnnZE5oz71+pPu=xSHQBeDM649NKMuOxfhATWAzx22g(at)mail(dot)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2019-08-22 09:43:30 | Re: Remove page-read callback from XLogReaderState. |
Previous Message | Peter Eisentraut | 2019-08-22 08:56:19 | Re: Make SQL/JSON error code names match SQL standard |