From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "Amitabh Kant" <amitabhkant(at)gmail(dot)com>, "pgsql-performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Limit & offset effect on query plans |
Date: | 2012-12-13 17:12:50 |
Message-ID: | 7063.1355418770@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Kevin Grittner" <kgrittn(at)mail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-12-13 18:14:32 | Re: Limit & offset effect on query plans |
Previous Message | Ghislain ROUVIGNAC | 2012-12-13 17:10:04 | Slow queries after vacuum analyze |