Hi,
I'm not very impressed with that patch, even discounting the
sum-vs-product thinko. Trawling the tlist for SRFs will add a significant
number of cycles, to modify the rowcount in a way that is practically
always wrong (since the estimates for SRF output rowcounts are so bad).
It's
Another email which went into the wilderness when I sent it to pgsql-patches.
Regards,
Nikhils
-- Forwarded message --
From: Nikhil Sontakke nikhil.sonta...@enterprisedb.com
Date: Fri, Apr 16, 2010 at 6:50 PM
Subject: row estimation off the mark when generate_series calls are
Nikhil Sontakke nikhil.sonta...@enterprisedb.com wrote:
I observed the following behavior on PG head:
postgres=# explain verbose insert into public.x values
(generate_series(1,10));
Insert (cost=0.00..0.01 rows=1 width=0)
Hmmm, there are
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
Nikhil Sontakke nikhil.sonta...@enterprisedb.com wrote:
I think the place where we set the
targetlist of the result_plan to sub_tlist, immediately after that we
should update the plan_rows estimate by walking this latest
targetlist. I
