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

Re: slow DELETE on 12 M row table

From: Marcin Stępnicki <mstepnicki(at)gmail(dot)com>
To: Janet Jacobsen <jsjacobsen(at)lbl(dot)gov>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: slow DELETE on 12 M row table
Date: 2009-06-26 10:40:40
Message-ID: 179149fe0906260340o77e0bfd3n8913341e115ce995@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Jun 26, 2009 at 9:34 AM, Janet Jacobsen<jsjacobsen(at)lbl(dot)gov> wrote:

> I assume that killing the user's process released the lock on the
> table.  This user has only SELECT privileges.  Under what
> conditions would a SELECT lock a table.  The user connects
> to the database via a (Python?) script that runs on another
> machine.  Would this way of connecting to the database result
> in a lock?

Was this process 'idle in transaction' perhaps? Does this Python
script use any ORM, like SQLAlchemy? If not, which library does it use
to connect? If it's psycopg2, which isolation level (autocommit, read
committed, serializable) is set?

Regards,
Marcin

In response to

Responses

pgsql-performance by date

Next:From: Greg SmithDate: 2009-06-26 14:33:24
Subject: Re: GiST index performance
Previous:From: Janet JacobsenDate: 2009-06-26 07:34:07
Subject: Re: slow DELETE on 12 M row table

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