On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov <lepi...@gmail.com> wrote: > 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.
Segfault appears to be caused by a typo. Patch used parent rinfo instead of child rinfo. Fixed in the attached patch. It appears that your first query also changed a plan after fixing this. Could you, please, provide another example of a regression for short-circuit optimization, which is related to this patch? Also, I've integrated your fix from [1]. Links. 1. https://www.postgresql.org/message-id/41ba3d47-2a48-476c-88d4-6ebd889a7af2%40gmail.com ------ Regards, Alexander Korotkov Supabase
v46-0001-Allow-usage-of-match_orclause_to_indexcol-for-jo.patch
Description: Binary data
