Aaron Guyon writes:
> We are currently running postgres 8.2 and are evaluating the upgrade to 8.3.
> Some of our tests are indicating that postgresql 8.3 is actually degrading
> the performance of some of our queries by a factor of 10 or more.
Are you sure you are comparing apples to apples here?
Hi,
We are currently running postgres 8.2 and are evaluating the upgrade to 8.3.
Some of our tests are indicating that postgresql 8.3 is actually degrading
the
performance of some of our queries by a factor of 10 or more. The queries
in
question are selects that are heavy on joins (~10 tables) w
On Mon, Mar 2, 2009 at 2:24 PM, Tim Bunce wrote:
> On Mon, Mar 02, 2009 at 02:29:31PM -0500, Tom Lane wrote:
>> Brian Cox writes:
>> > select locktype,database,relation,virtualxid,virtualtransaction,pid,mode
>> > from pg_locks order by mode;
>>
>> If you hadn't left out the "granted" column we co
On Mon, Mar 02, 2009 at 02:29:31PM -0500, Tom Lane wrote:
> Brian Cox writes:
> > select locktype,database,relation,virtualxid,virtualtransaction,pid,mode
> > from pg_locks order by mode;
>
> If you hadn't left out the "granted" column we could be more sure,
> but what it looks like to me is the
Tom Lane [...@sss.pgh.pa.us] wrote:
Well, that's certainly a sufficient reason, if perhaps not the only
reason. Dropping ts_defects_20090227 will require removal of FK triggers
on ts_transets, and we can't do that concurrently with transactions that
might be trying to fire those triggers.
Now a
Brian Cox writes:
> So, the idle transaction is the problem. Thanks to you, Scott Carey and
> Robert Haas for pointing this out. However, why does the drop of
> ts_defects_20090227 need exclusive access to ts_transets? I assume it
> must be due to this FK?
> alter table ts_defects_20090227 add
Tom Lane [...@sss.pgh.pa.us] wrote:
If you hadn't left out the "granted" column we could be more sure,
but what it looks like to me is the DROP (pid 13842) is stuck behind
the transaction (pid 13833). In particular these two rows of
pg_locks look like a possible conflict:
> relation |
Brian Cox writes:
> select locktype,database,relation,virtualxid,virtualtransaction,pid,mode
> from pg_locks order by mode;
If you hadn't left out the "granted" column we could be more sure,
but what it looks like to me is the DROP (pid 13842) is stuck behind
the transaction (pid 13833). In pa
On Mon, Mar 2, 2009 at 1:22 PM, Brian Cox wrote:
> As you can see there are only 3 transactions and 1 starts 1 hour after
> the drop begins. I'm still trying to figure out how to interpret the
> pg_locks output, but (presumably) you/others on this forum have more
> experience at this than I.
I'm
In my experience, 13833, " in transaction" is your culprit. It is a
transaction that has been there for 10 hours longer than all others, and is
doing nothing at all. It has locks on a lot of objects in there. You'll have
to take the oid's in the lock table and look them up in the pg_class tab
Tom Lane [...@sss.pgh.pa.us] wrote:
[ shrug... ] You tell us. To me it sounds a whole lot like some client
program sitting on an open transaction that has a nonexclusive lock on
the table to be dropped. That transaction wasn't necessarily doing any
useful work; it might have just been waiting
11 matches
Mail list logo
