Robert Haas <robertmh...@gmail.com> writes: > On Tue, Jun 13, 2017 at 10:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Well, the fundamental problem is that the RTE is a lousy place to keep >> rowcount estimates. That breaks assorted desirable properties like >> querytrees being readonly to planning/execution (not that we don't >> end up copying them anyway, but up to now that's been because of bad >> implementation not because the representation was broken by design).
> How does it break those properties? I don't think enrtuples is being > modified by planning or execution as things stand. 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. Thomas noted upthread that there wasn't any API for injecting a rowcount estimate from an SPI caller, which is wrong actually: there's already an enrtuples field in EphemeralNamedRelationMetadata. So another way to explain why this is broken is that having a field in the RTE is redundant with that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers