On Thu, 2005-10-20 at 16:54 -0600, Robert Creager wrote:
> On Thu, 20 Oct 2005 23:28:21 +0100
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > If the CS is the same, then it will tell us that the issue is not data
> > dependent. If the CS drops, it tells us that it is an activity performed
> > on the precise data blocks rather than the shared data structures which
> > is the issue. That would then account for why the effect appears to come
> > and go in your own application, because the effect is actually dependant
> > on the data distribution (which presumably varies in your tables).
>
> The CS is the same on both 7.4.1 and 8.1b3 (with 8.1b3 showing 100k and 7.4.1
> showing 170k using three clients). I double checked the scripts to make
> sure...
So that means it is either a generic issue or likely to be a lwlock
issue on the main named locks. The drop in CS between releases is
consistent with the overall drop in contention as a result of the
redesign of the buffer manager.
Does definitely look like spinlock issues on that platform. It would be
good to test this on a much newer system. Tuning for older hardware
doesn't seem that worthwhile (no shouting, please!).
It would be good right now to have a multi-process test harness that
would allow us to test out different spin lock code without the rest of
PostgreSQL getting in the way of testing. If we can isolate the issue
outside of PostgreSQL it will be much easier to fix. Any hackers out
there looking to set up a spinlock test harness?
Best Regards, Simon Riggs
---------------------------(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
