Re: Tuple count used while costing MergeAppend and that for an append rel

Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> AFAIU, There's difference in the tuples and rows members of
> RelOptInfo. While tuples gives the estimate of number of tuples per
> pg_class, rows gives the number of rows output by that relation. From
> that perspective rel->tuples should be set of the sum of
> child_rel->tuples from each of the children. If we do that the last
> argument to cost_merge_append() should change from rel->tuples to
> rel->rows.

> Does that make sense? Attached patch makes those changes.

AFAICS, what you propose to add in set_append_rel_size is pure overhead.
There's no conceivable use to computing sum-of-raw-tuple-counts for an
appendrel ... or at least, if there is, you didn't say what you expect
it would be good for. Normally the difference between rel->tuples and
rel->rows corresponds to the selectivity of the rel's restriction clauses.
Since an appendrel has no restrictions of its own (they've all been pushed
down to the child rels) it doesn't seem unreasonable for it to have tuples
equal to rows. While we could also define it as you suggest, I don't see
the point of expending extra cycles to do so.

I concur that using path->rows not rel->tuples in create_merge_append_path
would be an improvement. I think it makes no difference now, but if we
were to support parameterized mergeappend paths, rel->rows and rel->tuples
would both be wrong for such a path. (I believe the possibility of a
parameterized path is the reason why create_append_path computes
path->rows the hard way instead of just copying it from rel->rows.
The logic in create_merge_append_path was probably just copied from
create_append_path; it's overkill today but might not be so forever.)

regards, tom lane