Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wv6SH-0001yf-JM for pgsql-performance@arkaria.postgresql.org; Thu, 12 Jun 2014 14:58:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wv6SG-00044e-QM for pgsql-performance@arkaria.postgresql.org; Thu, 12 Jun 2014 14:58:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wv6SD-0003xk-23 for pgsql-performance@postgresql.org; Thu, 12 Jun 2014 14:58:13 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Wv6S9-0007ZD-0u for pgsql-performance@postgresql.org; Thu, 12 Jun 2014 14:58:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s5CEw6L0024298; Thu, 12 Jun 2014 10:58:06 -0400 From: Tom Lane To: Matt Silverlock cc: pgsql-performance@postgresql.org Subject: Re: OFFSET/LIMIT - Disparate Performance w/ Go application In-reply-to: <1D92FBC7-76DD-4B96-86E5-4989878C2847@eatsleprepeat.net> References: <1D92FBC7-76DD-4B96-86E5-4989878C2847@eatsleprepeat.net> Comments: In-reply-to Matt Silverlock message dated "Thu, 12 Jun 2014 15:08:27 +0800" Date: Thu, 12 Jun 2014 10:58:06 -0400 Message-ID: <24297.1402585086@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Matt Silverlock writes: > Hi all. This might be tricky in so much as there’s a few moving parts (when isn’t there?), but I’ve tried to test the postgres side as much as possible. > Trying to work out a potential database bottleneck with a HTTP application (written in Go): > Pages that render HTML templates but don’t perform DB queries can hit ~36k+ req/s > Pages that perform a SELECT on a single row net about ~6.6k req/s: db.Get(l, "SELECT * FROM listings WHERE id = $1 AND expiry_date > current_date", l.Id) > Pages that SELECT multiple rows with OFFSET and LIMIT conditions struggle to top 1.3k req/s You don't show us exactly what you're doing with OFFSET/LIMIT, but I'm going to guess that you're using it to paginate large query results. That's basically always going to suck: Postgres has no way to implement OFFSET except to generate and then throw away that number of initial rows. If you do the same query over again N times with different OFFSETs, it's going to cost you N times as much as the base query would. If the application's interaction with the database is stateless then you may not have much choice, but if you do have a choice I'd suggest doing pagination by means of fetching from a cursor rather than independent queries. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance