From: | Sheer El-Showk <sheer(at)saraf(dot)com> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: concurrency performance degradation |
Date: | 2001-10-27 06:31:29 |
Message-ID: | Pine.LNX.4.33.0110270230130.634-100000@laudanum.saraf.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I tried disabling foreign keys to test this and I didn't see a real
performance increase. Does setting pgenable in the pg_trigger table to
false disable all the foreign keys?
Is there any way to get a good trace of the locks or lock contention?
Thanks,
Sheer
On Fri, 26 Oct 2001, Stephan Szabo wrote:
> On Fri, 26 Oct 2001, Sheer El-Showk wrote:
>
> > Hi,
> >
> > I have an application that uses foreign keys rather heavily in postgres.
> > It supports multiple concurrent sessions with high transaction volumes.
> > Ideally the server should be able to have 20-30 connections open to the
> > database each partaking in similar operations. Each transaction may
> > involve 20+ writes and maybe 100 reads.
> >
> > When run single threaded, I can perform on transaction per second (30 or
> > so writes, 100 or so reads, plus time spent int he application), but if I
> > increase concurrency to about 10 active threads all doing similar
> > operations (on the same set of tables) I gain very little from it. I
> > notice in the process listing that the postges processes are almost all in
> > "INSERT WAITING..." or "UPDATE WAITING..." except for one which is in a
> > "SELECT" of an "INSERT". My confusion here is that I thought postgres
> > used record-level locking so I should be able run multipel concurrent
> > inserts on a table without locking.
> >
> > The reason I mention foreign keys above is that I imagine that foreign
> > keys might complicate locking issues and I use them a _lot_. I also
>
> If you're doing alot of inserts or updates to rows that match the same row
> in the primary key table this may be explained by the foreign key locking
> as I believe a row lock is grabbed on the primary key row to prevent
> it from being removed by another transaction.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Pilsl | 2001-10-27 06:45:25 | function given current output-row |
Previous Message | Stephan Szabo | 2001-10-27 06:30:13 | Re: concurrency performance degradation |