Re: PostgreSQL strugling during high load

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mindaugas Riauba" <mind(at)bi(dot)lt>
Cc: "Cosimo Streppone" <cosimo(at)streppone(dot)it>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL strugling during high load
Date: 2005-05-13 16:42:44
Message-ID: 24733.1116002564@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Mindaugas Riauba" <mind(at)bi(dot)lt> writes:
> Hm. Yes. Number of locks varies quite alot (10-600). Now what to
> investigate
> further? We do not use explicit locks in our functions. We use quite simple
> update/delete where key=something;
> Some sample (select * from pg_locks order by pid) is below.

The sample doesn't show any lock issues (there are no processes waiting
for ungranted locks). The thing that typically burns people is foreign
key conflicts. In current releases, if you have a foreign key reference
then an insert in the referencing table takes an exclusive row lock on
the referenced (master) row --- which means that two inserts using the
same foreign key value block each other.

You can alleviate the issue by making all your foreign key checks
deferred, but that just shortens the period of time the lock is held.
There will be a real solution in PG 8.1, which has sharable row locks.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mischa Sandberg 2005-05-13 17:33:22 Re: PostgreSQL strugling during high load
Previous Message Josh Berkus 2005-05-13 16:22:11 Re: Recommendations for set statistics