Re: Index Skip Scan
От | Dmitry Dolgov |
---|---|
Тема | Re: Index Skip Scan |
Дата | |
Msg-id | 20200217162451.nrpy5k63f5y2mwm6@localhost обсуждение исходный текст |
Ответ на | Re: Index Skip Scan (Dmitry Dolgov <9erthalion6@gmail.com>) |
Ответы |
Re: Index Skip Scan
|
Список | pgsql-hackers |
> On Fri, Feb 14, 2020 at 01:18:20PM +0100, Dmitry Dolgov wrote: > > On Fri, Feb 14, 2020 at 05:23:13PM +0900, Kyotaro Horiguchi wrote: > > The first attached (renamed to .txt not to confuse the cfbots) is a > > small patch that makes sure if _bt_readpage is called with the proper > > condition as written in its comment, that is, caller must have pinned > > and read-locked so->currPos.buf. This patch reveals many instances of > > breakage of the contract. > > Thanks! On top of which patch version one can apply it? I'm asking > because I believe I've addressed similar issues in the last version, and > the last proposed diff (after resolving some conflicts) breaks tests for > me, so not sure if I miss something. > > At the same time if you and Tomas strongly agree that it actually makes > sense to make moving forward/reading backward case work with dead tuples > correctly, I'll take a shot and try to teach the code around _bt_skip to > do what is required for that. I can merge your changes there and we can > see what would be the result. Here is something similar to what I had in mind. In this version of the patch IndexOnlyNext now verify if we returned to the same position as before while reading in opposite to the advancing direction due to visibility checks (similar to what is implemented inside _bt_skip for the situation when some distinct keys being eliminated due to scankey conditions). It's actually not that invasive as I feared, but still pretty hacky. I'm not sure if it's ok to compare resulting heaptid in this situation, but all the mention tests are passing. Also, this version doesn't incorporate any planner feedback from Tomas yet, my intention is just to check if it could be the right direction.
Вложения
В списке pgsql-hackers по дате отправления: