From: | Nandakumar M <m(dot)nanda92(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used |
Date: | 2018-02-02 15:49:50 |
Message-ID: | CANcFUu61n9UccHmzM6tmRxoH=rAX9xs2bxJC-MbWMW+qK_Z7ig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On Fri, Feb 2, 2018 at 8:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> The planner does not consider this and it doesn't really seem like
> something worth expending cycles on. If you know that there won't be
> nulls in the column, why are you insisting on specifying a nondefault
> value of NULLS FIRST/LAST in the query?
The query is generated by a framework that adds 'nulls last' to all
order by clause.
This is done apparently to provide common behaviour in our application
irrespective of the database that is used.
SQL server treats nulls as lesser than non null values which is
opposite to what Postgres does.
For any indexes that we create manually, we can do a
--> create index on table_name(column_name nulls first);
But, for the PK column we are not in control of the index that is created.
Regards,
Nanda
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2018-02-02 15:58:42 | Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used |
Previous Message | Tom Lane | 2018-02-02 15:00:16 | Re: Query optimiser is not using 'not null' constraint when 'order by nulls last' clause is used |