RE: Index Skip Scan - Mailing list pgsql-hackers

From Floris Van Nee
Subject RE: Index Skip Scan
Date
Msg-id 8e4710f8d4004905af454a43d72c41a5@opammb0562.comp.optiver.com
Whole thread Raw
In response to Re: Index Skip Scan  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
>
> * Suspicious performance difference between different type of workload,
>   mentioned by Tomas (unfortunately I had no chance yet to investigate).
>

His benchmark results indeed most likely point to multiple comparisons being done. Since the most likely place where
theseoccur is _bt_readpage, I suspect this is called multiple times. Looking at your patch, I think that's indeed the
case.For example, suppose a page contains [1,2,3,4,5] and the planner makes a complete misestimation and chooses a skip
scanhere. First call to _bt_readpage will compare every tuple on the page already and store everything in the
workspace,which will now contain [1,2,3,4,5]. However, when a skip is done the elements on the page (not the workspace)
arecompared to find the next one. Then, another _bt_readpage is done, starting at the new offnum. So we'll compare
everytuple (except 1) on the page again. Workspace now contains [2,3,4,5]. Next tuple we'll end up with [3,4,5] etc. So
tuple5 actually gets compared 5 times in _bt_readpage alone. 

-Floris




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()
Next
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()