Re: slow DELETE on 12 M row table
| От | Marcin Stępnicki |
|---|---|
| Тема | Re: slow DELETE on 12 M row table |
| Дата | |
| Msg-id | 179149fe0906260340o77e0bfd3n8913341e115ce995@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: slow DELETE on 12 M row table (Janet Jacobsen <jsjacobsen@lbl.gov>) |
| Ответы |
Re: slow DELETE on 12 M row table
|
| Список | pgsql-performance |
On Fri, Jun 26, 2009 at 9:34 AM, Janet Jacobsen<jsjacobsen@lbl.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
В списке pgsql-performance по дате отправления: