Re: Surprising SeqScan of appendRel that can't contribute any rows to the result

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Dmytro Astapov <dastapov(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Surprising SeqScan of appendRel that can't contribute any rows to the result
Date: 2024-12-18 01:40:21
Message-ID: 2549068.1734486021@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 18 Dec 2024 at 12:17, Dmytro Astapov <dastapov(at)gmail(dot)com> wrote:
>> Surprisingly, this does SeqScan on partB in NestedLoops over some_ids with a filter `some_ids.id = NULL::bigint`:

> TL;DR is it's not a bug and expected behaviour.

The particular case shown here might be fixable by re-applying
eval_const_expressions after we've derived the pushed-down qual.
Most of the time that'd be a waste of cycles though, and I'm
not sure how often it would help.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-12-18 02:22:00 Re: Not able to restore database - error: could not decompress data: Allocation error : not enough memory
Previous Message Dmytro Astapov 2024-12-18 00:36:32 Re: Surprising SeqScan of appendRel that can't contribute any rows to the result