Postgres: удивительная производительность при обновлении с использованием курсора - PullRequest
Новая
       16

Postgres: удивительная производительность при обновлении с использованием курсора

2 голосов
/ 23 января 2011

Рассмотрим два следующих примера кода Python, которые достигают того же, но со значительной и удивительной разницей в производительности. 

import psycopg2, time

conn = psycopg2.connect("dbname=mydatabase user=postgres")
cur = conn.cursor('cursor_unique_name')  
cur2 = conn.cursor()

startTime = time.clock()
cur.execute("SELECT * FROM test for update;")
print ("Finished: SELECT * FROM test for update;: " + str(time.clock() - startTime));
for i in range (100000):
    cur.fetchone()
    cur2.execute("update test set num = num + 1 where current of cursor_unique_name;")
print ("Finished: update starting commit: " + str(time.clock() - startTime));
conn.commit()
print ("Finished: update : " + str(time.clock() - startTime));

cur2.close()
conn.close()

И 

import psycopg2, time

conn = psycopg2.connect("dbname=mydatabase user=postgres")
cur = conn.cursor('cursor_unique_name')  
cur2 = conn.cursor()

startTime = time.clock()
for i in range (100000):
    cur2.execute("update test set num = num + 1 where id = " + str(i) + ";")
print ("Finished: update starting commit: " + str(time.clock() - startTime));
conn.commit()
print ("Finished: update : " + str(time.clock() - startTime));

cur2.close()
conn.close()

Оператор создания для проверки таблицы: 

CREATE TABLE test (id serial PRIMARY KEY, num integer, data varchar);

И эта таблица содержит 100000 строк и VACUUM ANALYZE TEST; был запущен.

Я получил следующие результаты последовательно при нескольких попытках.

Первый пример кода: 

Finished: SELECT * FROM test for update;: 0.00609304950429
Finished: update starting commit: 37.3272754429
Finished: update : 37.4449708474

Второй пример кода: 

Finished: update starting commit: 24.574401185
Finished committing: 24.7331461431

Это очень удивительно для меня, так как я думаю, что должно быть в точности наоборот, то есть обновление с использованием курсора должно быть значительно быстрее согласно этому ответу.

1 Ответ

4 голосов
/ 24 января 2011

Я не думаю, что тест сбалансирован - ваш первый код извлекает данные из курсора, затем обновляет, тогда как второй обновляет данные вслепую по идентификатору без извлечения данных.Я предполагаю, что первая последовательность кода преобразуется в команду FETCH, за которой следует UPDATE - так что это два обхода команды клиент / сервер, а не один.

(Также первый код начинается с блокировки каждой строки в таблице - это вытягиваетвся таблица в буферный кеш - хотя, думая об этом, я сомневаюсь, что это на самом деле влияет на производительность, но вы не упомянули об этом)

Также я думаю, что для простой таблицы не будет много другогомежду обновлением с помощью ctid (которое, как я предполагаю, работает where current of...) и обновлением с помощью первичного ключа - обновление pkey является дополнительным поиском по индексу, но если индекс не равен огромный , это не так уж и плохо.

Для такого обновления 100 000 строк я подозреваю, что большую часть времени занимает создание дополнительных кортежей и вставка их в таблицу или добавление их в таблицу, а не поиск предыдущего кортежа, чтобы пометить его как удаленный.

...