On Mon, Oct 5, 2020 at 2:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Actually, the reason I have been looking at equivclass.c is that I've
> been attacking the problem from a different direction. I'm fairly
> unexcited about making the definition of Var looser as you suggest
> here --- I actually think that it's dangerously imprecise already,
> due to not accounting for the effects of outer joins. However,
> we could avoid the growth in eclass members for large partition sets
> if we simply didn't store child eclass members, instead translating
> on-the-fly when we need to deal with child rels. I have a patch
> about half done, but it won't be possible to determine the true
> performance implications of that idea until it's all done. More
> later.
The thing that seems a bit dumb about the current system is that we
got to a lot of trouble to generate separte tlists and quals for every
inheritance child, but then in the final plan, what difference does it
make? I see that scan nodes, unlike joins etc., don't replace Var
nodes with INNER_VAR/OUTER_VAR, but it seems like a qual attached to a
Seq Scan has only one possible relation to which it can refer, so
what's the point of having separate lists with different varnos in
each? There is an issue if column numbering is different, because then
varattnos need to differ even at execution time, but it seems like the
only possible use of the varnos in these places is during planning. By
execution time, we can't really care any more, at least not as far as
I understand it.
Just to be clear, this is not a vote against whatever you want to do
to improve things in this area. It's just an observation that we seem
to create an awful lot of bulky data structures when planning a query
like SELECT * FROM many_children, and then don't do much with them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company