Re: CommandCounterIncrement versus plan caching

Tom Lane wrote:

> Once we have the knowledge of whether the current command ID is "dirty",
> we can skip everything inside CommandCounterIncrement when it is not;
> except for the AtStart_Cache() call, ie, AcceptInvalidationMessages().
> What that is looking for is asynchronous DDL-change notifications from
> other backends. I believe that it is actually not necessary for
> correctness for CCI to do that, because we should (had better) have
> adequate locking to ensure that messages about any particular table are
> absorbed before we touch that table. Rather, the reasoning for having
> this in CCI is to make sure we do it often enough in a long-running
> transaction to keep the sinval message queue from overflowing. 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.

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?

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Crear es tan difícil como ser libre" (Elsa Triolet)