On Tue, Feb 6, 2018 at 2:23 PM, Tom Lane wrote:
>> If we're going to have to change this at some point (and I bet we
>> are), I'd rather do it before people jam even more stuff into the
>> current system rather than wait until it gets totally out of hand.
>
> While I'm prepared to believe that thi
Robert Haas writes:
> On Fri, Feb 2, 2018 at 7:06 PM, Tom Lane wrote:
>> I'm disinclined to monkey with the way this works without someone
>> presenting hard evidence that it creates enough of a performance problem
>> to be worth spending a significant amount of time changing it. Up to
>> now I
On Fri, Feb 2, 2018 at 7:06 PM, Tom Lane wrote:
> We are not keeping a lock strong enough to prevent the relcache entry
> from changing altogether, e.g. an ANALYZE could commit midway through
> and change, say, the relpages/reltuples info. The consequences of
> that for consistent planner behavio
Robert Haas writes:
> Is there some good reason why get_relation_info() copies all of the
> data that will be needed later in planning into the RelOptInfo instead
> of just storing a pointer to the Relation directly into the
> RelOptInfo? Of course, if we did that, then it would have to leave
> t
Is there some good reason why get_relation_info() copies all of the
data that will be needed later in planning into the RelOptInfo instead
of just storing a pointer to the Relation directly into the
RelOptInfo? Of course, if we did that, then it would have to leave
the relation open instead of clo
