RE: Index Skip Scan
От | Floris Van Nee |
---|---|
Тема | RE: Index Skip Scan |
Дата | |
Msg-id | 80ef5f0744f542b18e508fb589a6425a@opammb0562.comp.optiver.com обсуждение исходный текст |
Ответ на | Re: Index Skip Scan (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Index Skip Scan
|
Список | pgsql-hackers |
> > > On Sun, Apr 05, 2020 at 04:30:51PM +0530, Dilip Kumar wrote: > > > > > > I was just wondering how the distinct will work with the "skip scan" > > > if we have some filter? I mean every time we select the unique row > > > based on the prefix key and that might get rejected by an external > > > filter right? > > Yeah, you're correct. This patch only handles the index conditions and doesn't handle any filters correctly. There's a checkin the planner for the IndexScan for example that only columns that exist in the index are used. However, this checkis not sufficient as your example shows. There's a number of ways we can force a 'filter' rather than an 'index condition'and still choose a skip scan (WHERE b!=0 is another one I think). This leads to incorrect query results. This patch would need some logic in the planner to never choose the skip scan in these cases. Better long-term solution isto adapt the rest of the executor to work correctly in the cases of external filters (this ties in with the previous visibilitydiscussion as well, as that's basically also an external filter, although a special case). In the patch I posted a week ago these cases are all handled correctly, as it introduces this extra logic in the Executor. -Floris
В списке pgsql-hackers по дате отправления: