Maarten Mortier <maarten.mortier@xxxxxxxxx> writes: > We have a jsonb_ops GIN index on this field, because we query the following > "freeform" match: > SELECT COUNT(id) > FROM records > WHERE data @@ '$.**.label == "person"'; > However, in the case of jsonb queries above, there is no need to do the > BitmapHeapScan really: the BitmapIndexScan has the correct row count, > always. This claim is wrong (in general) because of the need to verify visibility of the heap row. You might be able to look aside at the visibility map and find out that a particular heap page is all-visible, but unless the table is mostly static that can easily be a net waste of cycles. The reason we make a distinction between plain indexscans and index-only scans is to encode in the plan whether the planner thought such checks were likely to be a win. To transpose the idea into bitmapscans, you'd need similar infrastructure, which is not going to be a hack-it-in-one- place project. More to the point: I doubt this will help at all for the query above, because I doubt that the index is lossless for this query. From what I recall of GIN for jsonb, what it will return is TIDs for tuples that contain both "label" and "person". Whether they have the relationship of "person" being the value of a "label" tag can't be told without looking at the actual JSON value. regards, tom lane
