Оптимизация запросов PostgreSQL и процесс Postmaster '

Question

В настоящее время я работаю с базой данных PostgreSQL, созданной из дампов википедии он содержит около 40 ГБ данных. База данных работает на сервере HP Proliant ML370 G5 с Suse Linux Enterprise Server 10; Я запрашиваю его со своего ноутбука через частную сеть, управляемую простым маршрутизатором D-Link. Я назначил статические DHCP (частные) IP-адреса как ноутбуку, так и серверу.

В любом случае, с моего ноутбука, используя pgAdmin III, я отправляю некоторые команды / запросы SQL; некоторые из них - CREATE INDEX, DROP INDEX, DELETE, SELECT и т. д. Иногда я отправляю команду (например, CREATE INDEX), она возвращает сообщение о том, что запрос был выполнен отлично и т. д. Однако процесс postmaster, назначенный такому Кажется, команда остается спящей на сервере. Теперь я не против этого, поскольку говорю себе, что PostgreSQL поддерживает пул мастеров, готовых обрабатывать запросы. Тем не менее, если этот процесс израсходует 6 ГБ из этого 9,4 ГБ выделенной оперативной памяти, я переживаю (и сейчас это происходит). Теперь, возможно, это кэш данных, который хранится в [общей] памяти на случай, если другой запрос потребует использовать те же данные, но я не знаю.

Еще одна вещь беспокоит меня.

У меня есть 2 таблицы. Одним из них является таблица page ; У меня есть индекс в столбце page_id . Другой - это таблицы pagelinks , в которых есть столбец pl_from , который не ссылается ни на что, ни на переменную в столбце page.page_id ; в отличие от столбца page_id , у pl_from нет индекса (пока). Чтобы дать вам представление о масштабе таблиц и необходимости найти жизнеспособное решение, таблица page содержит 13,4 миллиона строк (после того, как я удалил ненужные мне), а Таблица ссылок имеет 293 миллиона.

Мне нужно выполнить следующую команду, чтобы очистить таблицу pagelinks от некоторых ее бесполезных строк:

DELETE FROM pagelinks USING page WHERE pl_from NOT IN (page_id);

Итак, в основном я хочу избавить таблицу pagelinks от всех ссылок, приходящих со страницы, не входящей в таблицу page . Даже после отключения вложенных циклов и / или последовательных проверок оптимизатор запросов всегда дает мне следующее «решение»:

Nested Loop  (cost=494640.60..112115531252189.59 rows=3953377028232000 width=6)
  Join Filter: ("outer".pl_from <> "inner".page_id)"
  ->  Seq Scan on pagelinks  (cost=0.00..5889791.00 rows=293392800 width=17)
  ->  Materialize  (cost=494640.60..708341.51 rows=13474691 width=11)
        ->  Seq Scan on page  (cost=0.00..402211.91 rows=13474691 width=11)

Кажется, что такая задача может занять больше недели; очевидно, это недопустимо. Мне кажется, я бы предпочел использовать индекс page_id для своей цели ... но это упрямый оптимизатор, и я могу ошибаться.

Answer 1

Действительно, я решил СОЗДАТЬ временную таблицу, чтобы ускорить выполнение запроса:

CREATE TABLE temp_to_delete AS(
    (SELECT DISTINCT pl_from FROM pagelinks) 
        EXCEPT 
    (SELECT page_id FROM page));
DELETE FROM pagelinks USING temp_to_delete 
    WHERE pagelinks.pl_from IN (temp_to_delete.pl_from);

Удивительно, но этот запрос был выполнен примерно за 4 часа, тогда как первоначальный запрос оставался активным в течение 14 часов, прежде чем я решил его убить. В частности, DELETE вернул:

Query returned successfully: 31340904 rows affected, 4415166 ms execution time.

Что касается первой части моего вопроса, кажется, что процесс postmaster действительно хранит некоторую информацию в кэше; когда для другого запроса требуется информация не в кеше, а в некоторой памяти (RAM), кеш очищается. А почтмейстеры - это действительно пул процессов ».

Мне также пришло в голову, что gnome-system-monitor является мифом, поскольку он дает неполную информацию и ничего не стоит в информационной ценности. В основном из-за этого приложения я так запутался в последнее время; например, он не учитывает использование памяти другими пользователями (например, пользователем postgres!) и даже говорит мне, что у меня осталось 12 ГБ ОЗУ, когда это не соответствует действительности. Поэтому я попробовал пару системных мониторов, так как мне хотелось бы знать, как postgreSQL использует его ресурсы, и кажется, что xosview действительно является допустимым инструментом.

Надеюсь, это поможет!

Answer 2

На ваш второй вопрос; вы можете попробовать создать новую таблицу с нужными записями с помощью оператора CREATE TABLE AS; если новая таблица достаточно мала, она может быть быстрее, но это тоже не поможет.

Answer 3

Ваш процесс postmaster будет оставаться там до тех пор, пока соединение с клиентом открыто. Pgadmin закрывает соединение? Я не знаю.

Используемая память может быть shared_buffers (проверьте настройки конфигурации) или нет.

Теперь запрос. Для больших операций обслуживания, подобных этой, не стесняйтесь устанавливать для work_mem что-то большое, например, несколько ГБ. Похоже, у вас много оперативной памяти, поэтому используйте ее.

установите для work_mem значение «4 ГБ»; ОБЪЯСНИТЬ УДАЛИТЬ ИЗ ссылок на страницы, ГДЕ pl_from НЕ ВХОДИТ (ВЫБЕРИТЕ page_id ИЗ СТРАНИЦЫ);

Он должен последовательно сканировать страницу, хэшировать и сканировать ссылки на страницы, заглядывая в хеш для проверки page_ids. Это должно быть довольно быстро (намного быстрее, чем 4 часа!), Но вам нужен большой work_mem для хэша.

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

СОЗДАТЬ ТАБЛИЦУ pagelinks 2 КАК ВЫБРАТЬ

(вы можете использовать простое JOIN вместо IN)

Вы также можете добавить ORDER BY к этому запросу, и ваша новая таблица будет аккуратно упорядочена на диске для оптимального доступа позже.