From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Nandakumar M <m(dot)nanda92(at)gmail(dot)com>, 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 09:36:40 |
Message-ID: | 1517564200.2452.10.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2018-02-01 at 20:00 +0530, Nandakumar M wrote:
> Hi,
>
> I am using Postgres version 9.4.4 on a Mac machine.
> I have 2 queries that differ only in the order by clause.
> One of it has 'nulls last' and the other one does not have it.
> The performance difference between the two is considerable.
>
> The slower of the two queries is
>
> SELECT [...]
> FROM workorder wo
> left join workorder_fields wof
> ON wo.workorderid=wof.workorderid
> left join servicecatalog_fields scf
> ON wo.workorderid=scf.workorderid
[...]
> ORDER BY 7 DESC nulls last limit 25
>
>
>
> On removing 'nulls last' from the order by clause the query becomes very fast.
> I have attached the query plan for both the queries.
In the above case, the optimizer does not know that it will get the rows
in the correct order: indexes are sorted ASC NULLS LAST by default,
so a backwards index scan will produce the results NULLS FIRST,
which is the default for ORDER BY ... DESC.
If you want the nulls last, PostgreSQL has to retrieve *all* the rows and sort
them rather than using the first 25 results it gets by scanning then indexes.
To have the above query perform fast, add additional indexes with either
ASC NULLS FIRST or DESC NULLS LAST for all used keys.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Vitaliy Garnashevich | 2018-02-02 11:46:22 | Re: effective_io_concurrency on EBS/gp2 |
Previous Message | Johan Fredriksson | 2018-02-02 09:02:07 | Re: SV: bad plan using nested loops |