Re: BUG #18477: A specific SQL query with "ORDER BY ... NULLS FIRST" is performing poorly if an ordering column is n

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 24 May 2024 at 22:03, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> But the NOT NULL constraint could be dropped at any minute, so the
>> system needs to know where NULLs would go if that were to happen.

> In my understanding, the planner will hold a lock that will prevent a
> concurrent session from doing ALTER TABLE ... DROP NOT NULL, so if the
> planner were to do an optimisation such as this, I think it should be
> safe. Can you explain where the hazard is?

This has nothing to do with the planner. The question Alvaro
responded to is whether the DDL definition of the index establishes
which end nulls should go at. Which it does, independently of whether
the table actually contains any nulls.

Yes, we could possibly set things up so that an index with nulls last
is considered to match a query that specifies NULLS FIRST if we know
that the column is not-nullable. But I refuse to believe that this
would be a good use of either development effort or planner cycles.
AFAICS the problem is purely self-inflicted damage: why is the user
specifying NULLS FIRST if he knows the column is not-null?

regards, tom lane