> > 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 suggested that change, just to keep the computation consistent with the comment in RelOptInfo. I agree that it's a pure overhead for now. If we were to maintain it per the comments, we may be able to find the average selectivity for an appendrel, but again, I do not see any real purpose in doing 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.) Yes, this code did puzzle me. add_path() does not allow paths to have both parameterization and pathkeys. So, a merge append on parameterized paths does look odd. But then, I thought, that producing a parameterized merge append would get allow merging ordered rows for a given value of parameter. Although we don't do that now, but may be it's useful in the future. Thanks a lot for your explanation. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers