From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Full page images in WAL & Cache Invalidation |
Date: | 2007-07-22 20:09:09 |
Message-ID: | 46A3B965.2070104@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-22 20:31:39 | Re: Full page images in WAL & Cache Invalidation |
Previous Message | Tom Lane | 2007-07-22 18:25:38 | Re: Full page images in WAL & Cache Invalidation |