Ah, his theory was that I got unlucky in my sample queries.
If I pick data that's much older in the table, then it would seem to
confirm his theory.
Index Only Scan using xx (cost=0.52..25.07 rows=1 width=19) (actual
time=0.032..0.039 rows=34 loops=1)
Index Cond: (a = 1654)
" Filter: (b = ANY
"Stephen Samuel (Sam)" writes:
> This index covers both columns needed in the predicate/projection, and the
> visibility bit is almost always set, why does it need to go to the heap at
> all and doesn't just get what it needs from the index?
Peter's theory was that the particular tuples you were
Just for my own knowledge:
This index covers both columns needed in the predicate/projection, and the
visibility bit is almost always set, why does it need to go to the heap at
all and doesn't just get what it needs from the index?
Or does scanning the _vm table count as a heap access in the plann
On Mon, Aug 19, 2024 at 12:06 AM Tom Lane wrote:
> > It was fixed? At least on 17.
>
> Oh, sorry, I was thinking of a related problem that doesn't apply
> here: matching indexes on expressions to fragments of a filter
> condition. However, the fact that the OP's EXPLAIN shows heap
> fetches from
Hello,
The query's behavior is expected due to how PostgreSQL handles composite
indexes and MVCC. The index on `(a, b)` is used efficiently for the `a`
condition, but the `b IN ()` filter is more complex, leading to
additional filtering rather than direct index usage. Although the
index-only scan
