Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lnkyb-0006gA-4r for pgsql-bugs@arkaria.postgresql.org; Mon, 31 May 2021 16:41:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lnkyY-0004n4-18 for pgsql-bugs@arkaria.postgresql.org; Mon, 31 May 2021 16:41:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lnkyX-0004mu-Eu for pgsql-bugs@lists.postgresql.org; Mon, 31 May 2021 16:41:13 +0000 Received: from xvm-110-146.dc2.ghst.net ([46.226.110.146] helo=fetter.org) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lnkyT-0003hA-QD for pgsql-bugs@lists.postgresql.org; Mon, 31 May 2021 16:41:12 +0000 Received: by fetter.org (Postfix, from userid 1001) id 88F4040C7D; Mon, 31 May 2021 18:41:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fetter.org; s=default; t=1622479265; bh=Os7Qz/In7GKkbnS1sJibYCoScOFi9ptw5GF673kVQ94=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tdFWApev6GABicR0lHJ00qhAE98v3ke0xQAY4PYNcQ/Hb68GFgGAorGxNHRFn6jTS t5DEb0iPjxI53SSaZ+3p/nEpamVJnDy+4kYr4UV/ckRMjjCOXDpB0vfOPri6XNpG21 WY+GrqW6rRTHn9uS0+YgYyhWIOwih6FeSPY3XDDBeAJvuD16iBJDS2o9eV7T6+vzvd tJvBu6GEaemXRG+xZUU4jVAfmMjKlQd9W0v6JkezPN8VEeNhaCrPc4hGq2eyvYuwBC IuoCqcPt8qtnmZPO8EKtEuqKGrWnVPEejfg8n8nQjPePkcG0H5fLIjZnwD2Kf78V5E tl5HV/1viaC2w== Date: Mon, 31 May 2021 16:41:05 +0000 From: David Fetter To: sreekanth vajrapu Cc: pgsql-bugs@lists.postgresql.org Subject: Re: Query is slow when order by and limit clause are used in the query Message-ID: <20210531164104.GA26722@fetter.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, May 24, 2021 at 04:19:01PM +0530, sreekanth vajrapu wrote: > Hi Team, > > We are having a slow query issue for one of our applications. We are seeing > slowness(5 seconds) when we use both ORDER BY and LIMIT 30 clause whereas > the same query is performing very good(200 MS) when using only ORDER BY > clause. Also note that the query performed very fast(200 MS) when we > increased LIMIT to 100 along with ORDER BY. > > Can you please help us if there are any bugs related to this? OR Can > someone kindly provide some solution to this issue? This is not at base a bug. Instead, it's a behavior which compliance with the SQL standard mandates. You're doing pagination, and unfortunately you're doing it in a way that, while it appears simple and intuitive, guarantees poor performance for later pages. Here's a concise description of the fundamental problem you're encountering along with some suggestions as to how to do this more efficiently, i.e. faster consistently. https://use-the-index-luke.com/no-offset Here are some more references on pagination and how to do it efficiently: http://www.depesz.com/2007/08/29/better-results-paging-in-postgresql-82/ https://wiki.postgresql.org/wiki/File:Pagination_Done_the_PostgreSQL_Way.pdf https://coderwall.com/p/lkcaag https://www.citusdata.com/blog/2016/03/30/five-ways-to-paginate/ https://ask.use-the-index-luke.com/questions/205/how-to-query-for-previous-page-with-keyset-pagination Best, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate