| From: | Vivek Khera <khera(at)kcilink(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: deferred foreign keys |
| Date: | 2004-01-05 19:02:00 |
| Message-ID: | A4624C54-3FB1-11D8-A8A5-000A9578CFCC@kcilink.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Jan 5, 2004, at 1:57 PM, Stephan Szabo wrote:
> But, if he's updating the fk table but not the keyed column, it should
> no
> longer be doing the check and grabbing the locks. If he's seeing it
> grab
> the row locks still a full test case would be handy because it'd
> probably
> mean we missed something.
>
I'm not *sure* it is taking any locks. The transactions appear to be
running lock step (operating on different parts of the same pair of
tables) and I was going to see if deferring the locks made the
difference. It is my feeling now that it will not. However, if there
is a way to detect if locks are being taken, I'll do that. I'd like to
avoid dropping and recreating the foreign keys if I can since it takes
up some bit of time on the table with 20+ million rows.
Vivek Khera, Ph.D.
+1-301-869-4449 x806
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Teran | 2004-01-05 19:02:01 | Re: optimizing Postgres queries |
| Previous Message | Vivek Khera | 2004-01-05 18:57:07 | Re: deferred foreign keys |