4 ms·
(Disclaimer: I'm an engineer at Timescale, I didn't work directly on this feature but have some knowledge of what it does). I'm not 100% sure I understand exac
by djk447 5y ago
(Disclaimer: I'm an engineer at Timescale, I didn't work directly on this feature but have some knowledge of what it does).
I'm not 100% sure I understand exactly what you're asking, but, perhaps some more info will be useful. First off, the goal with this isn't just to find the next unique item, it's to find the set of all the unique items, so you'd need to iterate the search, which is basically what the skipscan is doing internally.
Internally, the index is using something like a binary search (it's a btree, so slightly different, IIRC) to skip to the next unique item. A lot of the work here was in teaching the planner / executor to actually do that rather than the simpler, less efficient way that PG usually does it (brute force unique over a full scan). There's some more complexity on top of that in terms of teaching it to do that over all the chunks and then combine the results (because each has a separate index) and some more complexity in terms of knowing when you can use multi-column indexes and the like, but at its most basic level, it basically is using some sort of binary search to find the next item. But perhaps I'm missing what you're asking, feel free to clarify if I can better help here...
- knuthsat 5y agoIf index is ordered, I imagined it as a flat array. I would go to the next bigger item using binary search. I guess SkipScan does a similar thing but the index is a btree. Of course, things get more complicated when more tuples need to be distinct but I was a bit confused as to why the ordered property was not exploited by PG before (and still is not).