Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Leaving aside the btree issues, are you worried about performance
>> problems, or can aggressive cache flushing hurt correctness?
>
> It shouldn't hurt correctness, but I don't think you entirely grasp
> the magnitude of the performance hit you'll take. The last time I
> tried running the regression tests with CLOBBER_CACHE_ALWAYS enabled,
> they took about one hundred times longer than normal. Now you are
> evidently hoping not to disable the caches entirely, but I don't
> understand how you are going to handle the various random
> CacheInvalidateRelcache calls that are here and there in the system
> (not only in btree).
I must be missing something... A quick grep for CacheInvalidateRelcache
turned of these places:
src/backend/rewrite/rewriteDefine.c (EnableDisableRule)
src/backend/rewrite/rewriteSupport.c (SetRelationRuleStatus)
src/backend/access/nbtree/nbtinsert.c (_bt_insertonpg, _bt_newroot)
src/backend/access/nbtree/nbtpage.c (_bt_getroot, _bt_pagedel)
src/backend/commands/trigger.c (renametrig, EnableDisableTrigger)
src/backend/commands/cluster.c (mark_index_clustered)
src/backend/commands/indexcmds.c (DefineIndex)
src/backend/commands/tablecmds.c (setRelhassubclassInRelation)
src/backend/commands/vacuum.c (vac_update_relstats)
src/backend/catalog/heap.c (SetRelationNumChecks)
src/backend/catalog/index.c (index_drop, index_update_stats)
For CacheInvalidateHeapTuple, there is an additional hit in
src/backend/commands/vacuum.c (move_chain_tuple, move_plain_tuple).
Note that move_chain_tuple and move_plain_tuple are only called
in repair_frag, which in turn is only used in full_vacuum_rel.
Now, to me all of these with the exception of the btree functions,
vac_update_relstats and move_chain/plain_tuple look like they are only
called during DDL statements.
My basic assumption is that DDL is something quite uncommon on a
production system. This is obviously *totally* *wrong* for the
regression tests, and I don't doubt that my scheme will show quite
bad performance if you use that as a benchmark. But if you, say,
use pgbench for testing, than the picture will be quite different
I imagine.
My strategy would be the following
1) Mark the commit record if a transaction generated any invalidation events apart from the btree ones. The only
othersource of inval events seems to be "VACUUM FULL" on a system relation, which won't happen on a modestly
well-tunedsystem I think - any VACCUM FULL will need a special treatement anyway.
2) At replay time, the caches are flushed after that record was replayed.
greetings, Florian Pflug
