2012-03-02 6 views
2

У меня есть два запроса, вставка и обновление. Я сделал тест через консоль postgres с большим набором данных и обнаружил, что postgres не собирает индекс. Чтобы решить эту проблему - я отключил seqscan для этих двух запросов и получил огромное повышение производительности; Postgres смог забрать индексы для сканирования через таблицу.set enable_seqscan = off, через jdbc | Postgres

Проблема: Я делаю то же самое через JDBC

statement.executeUpdate("set enable_seqscan = off"); 
statement.executeUpdate("My_Insert_Query"); 
statement.executeUpdate("My_Update_Query"); 
statement.executeUpdate("set enable_seqscan = on"); 

Но похоже, Postgres не поворачивается seq_scan отправился и запросы принимают слишком много времени, чтобы выполнить.

Мастер Таблица

Master_Id auto-generated 
child_unique  integer 


Child Table 
child_unique integer 
Master_id integer 

Insert into Master (child_unique) from Child as i WHERE NOT EXISTS (SELECT * from Master where Master.child_unique = i.child_unique); 

Update Child set Master_id = Master.Master_id from Master where Master.child_unique = Child.child_unique; 

Для каждого уникального ряда в ребенке, который не присутствует в мастер- я ввожу, что в мой мастер-таблицу и получить автогенерируемую Master_ID и вставить его обратно в таблицу ребенка.

Обе таблицы имеют индекс для child_unique.

Указатель подбирается на главной таблице, где это не относится к таблице детей. Как я узнал? Использование таблицы pg_stat_all_indexes в Postgres.

+0

Некоторые параметры могут быть изменены только суперпользователями (я не знаю, какие из них), поэтому, если ваше приложение использует другого пользователя, то вы на консоли, который может быть проблемой. Также рекомендуется не переключать последовательное сканирование, а вместо этого настраивать константы затрат планировщика для вашего сервера: http://www.postgresql.org/docs/9.1/interactive/runtime-config-query.html#RUNTIME-CONFIG-QUERY -CONSTANTS. Для быстрого запуска, если ваша база данных полностью вписывается в память, сделайте random_page_cost равной seq_page_cost. Также убедитесь, что ваши данные были правильно проанализированы. – Eelke

+2

Почему вы не пытаетесь решить настоящую проблему? Почему PostgreSQL считает, что использовать индекс не рекомендуется? Не могли бы вы показать нам результат от EXPLAIN и/или EXPLAIN ANALYZE? –

+0

Вы подтвердили, что seqscan действительно отключен? Вы проверили план выполнения после его отключения? –

ответ

1

Во-первых, я согласен с Фрэнком выше - исправьте настоящую проблему.

Однако, если вы действительно хотите отключить seq-сканирование, вы не предоставили никакой информации, чтобы помочь вам в этом.

Выполнены ли все эти утверждения по одному и тому же соединению? (включите регистрацию в/в конфигурационном файле PostgreSQL, чтобы узнать)

Есть ли какие-либо другие jdbc-сгенерированные биты, отправляемые на сервер? (регистрация снова)

Что возвращает «show enable_seqscan» после первого утверждения?

+1

Примечание. Ребенок динамически создается внутри приложения и в рамках той же транзакции выполняются вышеуказанные SQL-запросы. Я узнал, что если я создам таблицу Child в другой транзакции и зафиксирую ее, у меня больше нет этой проблемы. Теперь проблема заключается в том, почему она не поднимает индекс внутри одной транзакции? – KarthikRajagopal

+0

Похож на проблему с ANALYZE: auto_vacuum (также отвечающий за авто ananlyze) срабатывает при создании новых записей. Но только после фиксации, используя собственное соединение с базой данных. Используйте ANALYZE Child; после вставок, используя ваше текущее соединение, и посмотрите, есть ли разница в запросе. –

Смежные вопросы