On Thu, 20 Oct 2005 23:28:21 +0100
Simon Riggs <simon@2ndquadrant.com> wrote:
> On Thu, 2005-10-20 at 14:59 -0600, Robert Creager wrote:
> > On Thu, 20 Oct 2005 21:19:18 +0100
> > Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > > Try this to recreate the problem:
> > > http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
> > >
> >
> > Yup, that does it. Three hits the level I see with my application ~100k.
> > Two hits about 50k, one does nothing (< 1k).
>
> OK, good. IYKWIM
>
> Can you try a slight modification?
>
> Run 3 threads, but against 3 different otherwise identical test tables
> created using a name-only mod of the test script. e.g. test_data1, 2 and
> 3.
I modified the setup to create the first table, then selected it into the second
two tables, all in the same database. Created three unique indexes (when I
didn't, there was no CS issue).
>
> This will hit a different pattern of lwlocks.
>
> 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...
Cheers,
Rob