| From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
|---|---|
| To: | Vivek Khera <khera(at)kcilink(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: deferred foreign keys |
| Date: | 2004-01-05 19:48:26 |
| Message-ID: | 20040105114730.U73612@megazone.bigpanda.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, 5 Jan 2004, Vivek Khera wrote:
>
> 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.
The only way I can think of to see the locks is to do just one of the
operations and then manually attempting to select for update the
associated pk row.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rod Taylor | 2004-01-05 19:52:06 | Re: Select max(foo) and select count(*) optimization |
| Previous Message | Tom Lane | 2004-01-05 19:23:45 | Re: optimizing Postgres queries |