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
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 |