Re: BUG #18442: Unnecessary Sort operator in indexScan Plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: hu_yajun(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18442: Unnecessary Sort operator in indexScan Plan
Date: 2024-04-22 02:25:42
Message-ID: 2909005.1713752742@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:
> Couldn't strict equality conditions be handled using the same method
> that we use to handle an Eclass with two distinct Consts. e.g a = 1
> and a=b and b=2?

Perhaps, but it'd be a bit odd and confusing to treat two NULLs as
distinct rather than equal.

On the whole I'm disinclined to add complexity around this. My gut
says there are more semantic gotchas than this one, and I think the
use-case is at best pretty hokey. If your data design requires using
NULL as though it's a normal data value, you're in a state of sin
already, and you're going to find SQL fighting you all the way.

(A question closely related to this is whether IS NOT DISTINCT FROM
could be optimized more like regular equality. I'm not convinced
about the use-case there either, although perhaps it's worth looking
into.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2024-04-22 06:16:08 Re: BUG #18442: Unnecessary Sort operator in indexScan Plan
Previous Message David Rowley 2024-04-22 01:53:02 Re: BUG #18442: Unnecessary Sort operator in indexScan Plan