On 1/13/25 10:39, Andrei Lepikhov wrote:
> On 1/13/25 01:39, Alexander Korotkov wrote:
> It can be resolved with a single-line change (see attached). But I need
> some time to ponder over the changing behaviour when a clause may match
> an index and be in joinorclauses.
In addition, let me raise a couple of issues:
1. As Robert has said before, it may interfere with some short-circuit
optimisations like below:
EXPLAIN (COSTS OFF)
SELECT * FROM bitmap_split_or t1
WHERE t1.a=2 AND (t1.b=2 OR t1.b = (
SELECT sum(c1.reltuples) FROM pg_class c1, pg_class c2
WHERE c1.relpages=c2.relpages AND c1.relpages = t1.a));
Here, a user may avoid evaluating the subplan at all if t1.b=2 all the
time when t1.a=2. OR->ANY may accidentally shift this behaviour.
2. The query:
EXPLAIN (ANALYZE, COSTS OFF)
SELECT * FROM bitmap_split_or t1
WHERE t1.a=2 OR t1.a = (
SELECT sum(c1.reltuples) FROM pg_class c1, pg_class c2
WHERE c1.relpages=c2.relpages AND c1.relpages = t1.a)::integer;
causes SEGFAULT during index keys evaluation. I haven't dived into it
yet, but it seems quite a typical misstep and is not difficult to fix.
--
regards, Andrei Lepikhov
