Hi!
On 25.01.2025 08:04, Alexander Korotkov wrote:
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
I started reviewing at the patch and saw some output "ERROR" in the
output of the test and is it okay here?
SELECT * FROM tenk1 t1
WHERE t1.thousand= 42OR t1.thousand= (SELECT t2.tenthousFROM tenk1 t2
WHERE t2.thousand= t1.tenthous);
ERROR: more than one row returned by a subquery used as an expression
--
Regards,
Alena Rybakina
Postgres Professional
