On Wed, Oct 27, 2021 at 1:02 AM Pavel Borisov <pashkin.e...@gmail.com> wrote: > AFAIK Gin is lossy for phrase queries as we don't store word position in the > posting list. For purely logical queries, where position doesn't matter, it's > not lossy.
GIN is always lossy, in the sense that it provides only a gingetbitmap() routine -- there is no gingettuple() routine. I believe that this is fundamental to the overall design of GIN. It would be very difficult to add useful gingettuple() functionality now, since GIN already relies on lossiness to avoid race conditions. Here's an example of the problems that "adding gingettuple()" would run into: Today, an index's pending list entries can be merged concurrently with the entry tree, without worrying about returning the same tuples twice. This is only safe/correct because GIN only supports bitmap index scans. Without that, you need some other mechanism to make it safe -- ISTM you must "logically lock" the index structure, using ARIES/KVL style key value locks, or something along those lines. -- Peter Geoghegan
