Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans)
От | Peter Geoghegan |
---|---|
Тема | Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans) |
Дата | |
Msg-id | CAH2-Wzk4xbvrUoc5CKJHNFgHZQbTy7CpT_2PMM=GtviY5CMFyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in nbtree optimization to skip > operator comparisons (or < comparisons in backwards scans) (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | pgsql-hackers |
On Wed, Dec 6, 2023 at 5:27 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > On Wed, 6 Dec 2023 at 14:11, Robert Haas <robertmhaas@gmail.com> wrote: > > It isn't very clear from the commit message that this commit is doing > > two different things, and in fact I'm still unclear on what exactly > > the other optimization is. > > I feel that Peter refered to these two distinct optimizations: Right. > 2. When scanning an index in ascending order using scankey a < 10 (one > that defines an endpoint of the scan), we can look ahead and check if > the last item on the page is consistent. If so, then all other items > on the page will also be consistent with that scankey. Also worth noting that it could be "scankey a = 10". That is, the precheck optimization (i.e. the optimization that's not the target of my test case) can deal with equalities and inequalities just as well (any scan key that's required in the current scan direction is supported). On the other hand the required-in-opposite-direction-only optimization (i.e. the target of my test case) only applies to inequality strategy scan keys. It kinda makes sense to explain both concepts using an example that involves both > and < strategy inequalities, since that makes the symmetry between the two optimizations clearer. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: