Hi Tom,
On 3/5/07 8:53 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Hm, that seems to blow the "it's an L2 cache effect" theory out of the
> water. If it were a cache effect then there should be a performance
> cliff at the point where the cache size is exceeded. I see no such
> cliff, in fact the middle part of the curve is darn near a straight
> line on a log scale ...
>
> So I'm back to asking what we're really measuring here. Buffer manager
> inefficiency of some sort, but what? Have you tried oprofile?
How about looking at the CPU performance counters directly using cpustat:
cpustat -c BU_fill_into_L2,umask=0x1 1
This shows us how many L2 fills there are on all four cores (we use all
four). In the case without buffer cache pollution, below is the trace of L2
fills. In the pollution case we fill 27 million lines, in the pollution
case we fill 44 million lines.
VACUUM orders (no buffer pollution):
51.006 1 tick 2754293
51.006 2 tick 3159565
51.006 3 tick 2971929
51.007 0 tick 3577487
52.006 1 tick 4214179
52.006 3 tick 3650193
52.006 2 tick 3905828
52.007 0 tick 3465261
53.006 1 tick 1818766
53.006 3 tick 1546018
53.006 2 tick 1709385
53.007 0 tick 1483371
And here is the case with buffer pollution:
VACUUM orders (with buffer pollution)
22.006 0 tick 1576114
22.006 1 tick 1542604
22.006 2 tick 1987366
22.006 3 tick 1784567
23.006 3 tick 2706059
23.006 2 tick 2362048
23.006 0 tick 2190719
23.006 1 tick 2088827
24.006 0 tick 2247473
24.006 1 tick 2153850
24.006 2 tick 2422730
24.006 3 tick 2758795
25.006 0 tick 2419436
25.006 1 tick 2229602
25.006 2 tick 2619333
25.006 3 tick 2712332
26.006 1 tick 1827923
26.006 2 tick 1886556
26.006 3 tick 2909746
26.006 0 tick 1467164
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
