Re: CommandCounterIncrement versus plan caching

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Tom Lane wrote:
>> ... I am
>> tempted to remove that from CCI and call it from just a selected few CCI
>> call sites, instead --- maybe only CommitTransactionCommand. OTOH this
>> step might reasonably be considered too risky for late beta, since it
>> would affect asychronous backend interactions, which are way harder to
>> test properly than within-a-backend behavior.

> I agree that it seems risky to remove it at this point. It could have
> severe performance impact if it turns out that not calling it enough
> causes the queue to overflow. It seems safer to be calling it as
> frequently as possible.

Yeah, I left it alone for the moment. It should be revisited someday.

> I was going to say, what would happen if vacuum were to run on a large
> table and a high vacuum_delay setting, but then I noticed that currently
> it doesn't call CCI at all. Is this a concern?

It's always been the case that long-running queries might not call
AcceptInvalidationMessages for a very long time. The worst-case
consequence is a system cache flush, which might be annoying from
a performance point of view but shouldn't be a problem otherwise.
Again, it's not something I care to mess with right now.

One thought is that the typical case would probably involve only one or
two laggard backends. Right now, we handle queue overflow by discarding
*all* pending messages and forcing a cache reset instead in *all*
backends. That's simple but it makes every backend pay the performance
price. Might be worthwhile to teach it to discard, say, the oldest half
of the queued messages and only force reset for those backends that
hadn't eaten those yet. Then, a reset would be expected to occur only
within a backend that'd just finished a long-running query, and so the
relative performance cost should be small.

regards, tom lane