Well, there is a wrinkle: if the predicate returns `false` but one of the
columns is null then the whole thing ends up `true` when I'd want it to be
`false`. Say col_a = [1] and col_b = [null]:
WHERE (col_a < 1 AND col_b > 1) OR col_a IS NULL OR col_b IS NULL -> WHERE
(false AND null) OR false OR
Thank you for the great idea Tom. While yes I can't modify the original
WHERE clause I do think I'll be able to introspect it or get the system
generating it to tell me which columns it references and then add an OR x
is NULL OR y is NULL ...
For context, just in case it's interesting, I store Par
"David G. Johnston" writes:
> On Wednesday, December 18, 2024, Adrian Garcia Badaracco <
> adr...@adriangb.com> wrote:
>> Is there any way to include the rows where the predicate evaluates to null
>> while still using an index?
> ... A btree index, which handles =, can’t be told to behave
> diffe
On Wednesday, December 18, 2024, Adrian Garcia Badaracco <
adr...@adriangb.com> wrote:
>
> Is there any way to include the rows where the predicate evaluates to null
> while still using an index?
>
That seems quite unlikely. Your definition of equality is incompatible
with the system’s standard
I'll note that the clause is arbitrary in the sense that I don't generate
it and cannot edit it but it's basically a bunch of boolean comparisons
chained i.e. `col_a >= 1 and col_b <=5 and col_c ...` so I can in general
add an index on say col_a and it does get used.
On Wed, Dec 18, 2024 at 9:47 P
