Re: Query is slow when order by and limit clause are used in the query

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: sreekanth vajrapu <sreekanthvajrapu(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Query is slow when order by and limit clause are used in the query
Date: 2021-05-24 12:28:40
Message-ID: CALj2ACWYyYpUqWCLRan4GKPOkrcYXUVJ9g=u=Ynhs6FjyhxBCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, May 24, 2021 at 5:01 PM sreekanth vajrapu
<sreekanthvajrapu(at)gmail(dot)com> wrote:
>
> Hi Bharath,
>
> Thanks for the quick reply, I have attached the execution plan for below 3 scenarios. Our application is using 1st Scenario
>
> 1) WITH ORDER BY AND LIMIT 30 -- Very slow(3 to 5 seconds)
> 2) WITH ORDER BY WITHOUT LIMIT -- Very fast(160 MS)
> 3) WITH ORDER BY WITHOUT LIMIT 100 -- Very fast(160 MS)
>
> Kidney let me know if you need any more details on this.

I see that there are a huge number of Heap Fetches: 599354 with LIMIT
30 clause vs Heap Fetches: 11897 without LIMIT clause, maybe that
could be the reason for the slowness. I'm not sure why this is
happening with the LIMIT 30 clause only. Is it that this issue happens
every time? Say, if you run with LIMIT 30, then the query finishes in
3-5sec. Immediately if you run without a LIMIT clause then the query
completes in 160ms. Is vacuum running successfully on the tables and
indexes for which there's a huge number of heap fetches?

I have no further thoughts on this, other hackers may have better
suggestions though.

BTW, which version of postgresql are you using?

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tomas Vondra 2021-05-24 14:19:24 Re: Query is slow when order by and limit clause are used in the query
Previous Message sreekanth vajrapu 2021-05-24 11:31:28 Re: Query is slow when order by and limit clause are used in the query