Re: Index Skip Scan
От | David Rowley |
---|---|
Тема | Re: Index Skip Scan |
Дата | |
Msg-id | CAApHDvo1NF0Qv9ZdnuDu03=1JwEq7GiVa-q3Qu=aMzmD9SV-vQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Index Skip Scan (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Index Skip Scan
|
Список | pgsql-hackers |
On Wed, 11 Mar 2020 at 01:38, Dmitry Dolgov <9erthalion6@gmail.com> wrote: > > > >On Tue, Mar 10, 2020 at 09:29:32AM +1300, David Rowley wrote: > > There's also some weird looking assumptions that an EquivalenceMember > > can only be a Var in create_distinct_paths(). I think you're only > > saved from crashing there because a ProjectionPath will be created > > atop of the IndexPath to evaluate expressions, in which case you're > > not seeing the IndexPath. This results in the optimisation not > > working in cases like: > > I've read it as "an assumption that an EquivalenceMember can only be a > Var" results in "the optimisation not working in cases like this". But > you've meant that ignoring a ProjectionPath with an IndexPath inside > results in this optimisation not working, right? If so, then everything > is clear, and my apologies, maybe I need to finally fix my sleep > schedule :) Yes, I was complaining that a ProjectionPath breaks the optimisation and I don't believe there's any reason that it should. I believe the way to make that work correctly requires paying attention to the Path's uniquekeys rather than what type of path it is.
В списке pgsql-hackers по дате отправления: