Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> 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 other source of inval
   events seems to be "VACUUM FULL" on a system relation, which won't
   happen on a modestly well-tuned system 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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to