You are right…I flubbed the alter session set “_old_connect_by_enabled” = true…

With that in place I see 45.9 with a single stream and two-streams-same-table
come in at 57.2/57.4

As for the variant kslget implementations (e.g., t,t&s versus compare and swap) really
don’t make that much difference. In both cases they are looped and susceptible to
external interference such as interrupts in the control code (loop). These simple
spinlocks (latch) make too many presumptions such as the notion that the HOLDER of the
lock is actually on a CPU or that allowing any interested party to acquire the lock
is the best for the overall system…but, in the end, they do work pretty well with
today’s hardware…I suspect they’ll deserve a closer look as core count goes to 8 and
beyond though

Nice thought. I don’t know the answer, but I don’t believe that Oracle uses mutexes on buffer headers.

Intel 830 (Pentium 4) running at 2.1Ghz with 1Mb L2 cache I think, and DDR2 memory clocked at 533MHz (in case that’s significant)

Single run: 68 CPU seconds.
Two runs against same table: 90 / 92 CPU seconds (7.6M latch misses).
Running against two tables: 74 / 77 CPU seconds. (No latch anomalies)

I’m not keen on the variation, between concurrent runs – I’d have to guess it was some CPU scheduling issue; and it was pretty consistent.

I think this absolves the Windows port.

Thanks for the feedback – but could I just confirm that you didn’t manage to lose the line:

alter session set "_old_connect_by_enabled" = true;

When I take that out, my times on 11.1.0.6 are: 21.8 seconds for a single table, and 21.8 seconds for using the same table in two concurrent executions.

In my concurrency test with the “old connect by”, 11i went from 67 CPU seconds (single) to 75 CPU seconds (2 x same table).

The concurrency test I showed (9i) was the worst case one (a comment I’ve just added to the note) – and I picked that one because I’ve also demonstrated it on 9i running on HP-UX 11.00, whereas the 8i test showed latch sleeps. (I never got around to installing 10g on my old HP D370).

One random thought – is there any chance that the variation across versions might be related to changes in options for latching through “compare and swap” rather than “test and set” ?

…I just ran this on a 2s8c Xeon Clovertown box with Linux 2.6.18 and 11.1.0.6.1 and it gets 12.6 seconds with one invocation…2 concurrent same table is 12.68.

…a lot of what you are seeing is due to the fact that the turion can spin its way through the test and set ops quite fast (because that is all L2 spinning), but the load and store ops required for the latch get/work/release cycle is way off balance due to the (likely) poor memory latency of the laptop…just a way off-balance test I think…either that or it is an oddity of the Windows port (which I know little about)…what I’m trying to say is that one really shouldn’t see that many wait gets spin off to sleep…even on a 2 CPU laptop.

Meanwhile I feel that reduced Latch gets could be due to use of Mutexes. Not sure if some of Database buffer cache latches has been modified to use Mutexes (Similar to Library Cache latches and Pins)

Thank you so much for the excellent example and clear explanations.

I’ve no idea. Obviously we can expect the code path to get longer on each release – 9i, for example, adds in the code to update the v$segstat – and I am doing something that is designed to emphasize the overheads on buffer visits. But I saw no reason for the extreme change in 10g – possibly Oracle has implemented a new latch mechanism on this platform at this release.

In fact, in 11.1.0.6 the time dropped back to 67 CPU seconds. But in this case the statistics had also changed dramatically, so I saw:

8M latch gets instead of 32M
8M consistent gets instead of 16M

and the latter were mainly reported as

8M consistent gets from cache (fastpath)