From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 18:14:32 |
Message-ID: | 20121213181433.56870@gmx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> 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 ...)
Right, I was trying to isolate the cost, and in a more complex
query, or with results streaming back, that could easily be lost in
the noise. Assuming that the setup time for the node is trivial
compared to filtering 10,000 rows, the time per row which passes
through the limit node seems to be (very roughly) 140 nanoseconds
on an i7. I don't know whether that will vary based on the number
or types of columns.
I just tried with returning the results rather than running EXPLAIN
ANALYZE, and any difference was lost in the noise with only five
samples each way. I wonder how much of the difference with EXPLAIN
ANALYZE might have been from the additional time checking. Maybe on
a normal run the difference would be less significant.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-12-13 20:42:44 | Re: Slow queries after vacuum analyze |
Previous Message | Tom Lane | 2012-12-13 17:12:50 | Re: Limit & offset effect on query plans |