"Kevin Grittner" <kgrittn@xxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
