On Thu, 20 Oct 2005 23:28:21 +0100 Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-10-20 at 14:59 -0600, Robert Creager wrote: > > On Thu, 20 Oct 2005 21:19:18 +0100 > > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(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
