From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Kevin Grittner" <kgrittn@mail.com>
cc: "Pavan Deolasee" <pavan.deolasee@gmail.com>,
	"Amitabh Kant" <amitabhkant@gmail.com>,
	"pgsql-performance" <pgsql-performance@postgresql.org>
Subject: Re: Limit & offset effect on query plans
In-reply-to: <20121213170700.80080@gmx.com>
References: <20121213170700.80080@gmx.com>
Comments: In-reply-to "Kevin Grittner" <kgrittn@mail.com>
	message dated "Thu, 13 Dec 2012 12:07:00 -0500"
Date: Thu, 13 Dec 2012 12:12:50 -0500
Message-ID: <7063.1355418770@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

"Kevin Grittner" <kgrittn@mail.com> writes:
> Tom Lane wrote:
>> 1.35ms out of what?

> Without the limit node the runtimes (after "priming" the cache)
> were:

> 1.805, 2.533
> 1.805, 2.495
> 1.800, 2.446
> 1.818, 2.470
> 1.804, 2.502

> The first time for each run is "Total runtime" reported by EXPLAIN,
> the second is what psql reported from having \timing on.

> With the limit node:

> 3.237, 3.914
> 3.243, 3.918
> 3.263, 4.010
> 3.265, 3.943
> 3.272, 3.953

> I eyeballed that in the console window and said 1.35 based on rough
> in-my-head calculations, although with it laid out in a nicer
> format, I think I was a little low.

Huh, so on a percentage basis the Limit-node overhead is actually pretty
significant, at least for a trivial seqscan plan like this case.
(This is probably about the worst-case scenario, really, since it's
tough to beat a simple seqscan for cost-per-emitted-row.  Also I gather
you're not actually transmitting any data to the client ...)

			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