On Tue, Jun 13, 2017 at 12:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> But it needs to be changeable, unless you like the proposition that we >>> can never replan a query inside a trigger on the basis of new information >>> about how big the transition table is. Even if you're okay with that >>> particular restriction, the NamedTupleStore stuff is supposed to be >>> flexible enough to accommodate other use-cases, and some of them will >>> surely not be okay with an immutable estimate for the store's size. > >> Hmm, true. But even if we extracted enrtuples from the >> RangeTbleEntry, there wouldn't be any mechanism to actually trigger >> such a replan, would there? > > You're just pointing out that there's a lot of unfinished work around > this mechanism. I don't think anybody has claimed otherwise.
I'm just trying to understand your comments so that I can have an intelligent opinion about what we should do from here. Given that the replan wouldn't happen anyway, there seems to be no reason to tinker with the location of enrtuples for v10 -- which is exactly what both of us already said, but I was confused about your comments about enrtuples getting changed. I think that I am no longer confused. We still need to review and commit the minimal cleanup patch Thomas posted upthread (v1, not v2). I think I might go do that unless somebody else is feeling the urge to whack it around before commit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
