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 did that and now we seem to get proper row estimates.
> I agree the estimation should be improved, but your patch *adds*
> the estimated number of rows to the result:
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).
What's more, most of the time we don't really care, because the
top-level rowcount estimate is of no interest for future planning
purposes. It might be worth doing something about this inside
sub-selects, but not till we have less-bogus SRF rowcount estimates.
BTW, another reason for not being excited about this is that someday we
ought to disallow SRFs in the tlist altogether --- once we have LATERAL,
which might happen in 9.1, that will be a much more semantically
consistent way of getting the desired behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
