Skip site navigation (1) Skip section navigation (2)

Re: Blocking excessively in FOR UPDATE

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: sthomas(at)peak6(dot)com, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, postgres performance list <pgsql-performance(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Blocking excessively in FOR UPDATE
Date: 2011-11-07 20:26:13
Message-ID: CAGTBQpa-N+sQbgEzYfQWTDg643B3gf_83jOs0fMpfAC0QpDctg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Nov 4, 2011 at 4:07 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> Here again, you've set it to ten times the default value.  That
>> doesn't seem like a good idea.  I would start with the default and
>> tune down.
>
> Already did that. Waiting to see how it turns out.

Nope, still happening with those changes.

Though it did make sense that those settings were too high, it didn't
fix the strange blocking.

Is it possible that the query is locking all the tuples hit, rather
than only the ones selected?

Because the index used to reach the tuple has to walk across around 3k
tuples before finding the one that needs locking. They're supposed to
be in memory already (they're quite hot), that's why selecting is
fast, but maybe it's trying to lock all 3k tuples?

I don't know, I'm just throwing punches blindly at this point.

In response to

pgsql-performance by date

Next:From: Jay LevittDate: 2011-11-07 21:25:08
Subject: Subquery in a JOIN not getting restricted?
Previous:From: Jay LevittDate: 2011-11-07 20:15:23
Subject: Re: Predicates not getting pushed into SQL function?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group