Re: row estimation off the mark when generate_series calls are involved

Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
> Nikhil Sontakke <nikhil.sontakke@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