Re: Index INCLUDE vs. Bitmap Index Scan

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On 2/27/19 6:36 AM, Markus Winand wrote:
> On 27.02.2019, at 00:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> For example, given a filter condition like "1.0/c > 0.1", people
>>> would complain if it still got zero-divide failures even after they'd
>>> deleted all rows with c=0 from their table.

>> Ok, but I don’t see how this case different for key columns vs. INCLUDE columns.

> Yeah, I'm a bit puzzled by this difference too - why would it be safe
> for keys and not the other included columns?

It's not about the column, it's about the operator. We assume that
operators appearing in opclasses are safe to execute even for
index entries that correspond to dead rows. INCLUDE columns don't
have any associated opclass, hence no assumed-usable operators.

> I do recall a discussion about executing expressions on index tuples
> during IOS (before/without inspecting the heap tuple). I'm too lazy to
> search for the thread now, but I recall it was somehow related to
> leak-proof-ness. And AFAICS none of the "div" procs are marked as
> leak-proof, so perhaps that's one of the reasons?

Leak-proof-ness is kind of related, perhaps, but it's not quite the property
we're after here --- at least not to my mind. It might be an interesting
discussion exactly what the relationship is. Meanwhile, we don't have any
separate concept of functions that are safe to apply to any index entry;
opclass membership is it.

You could probably argue that any clause containing only indexed variables
and operators that are members of *some* opclass could be used as a filter
in advance of heap liveness checking. But we lack any infrastructure for
that, in either the planner or executor.

regards, tom lane