"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
