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

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

SELECT 
    contract.ctrId, 
    contract.ctrNr 
FROM 
    changeLog, 
    contract 
where 
    changelog.entid in (select contract.ctrid from contract where contract.ctrnr LIKE '1000002%');

Этот запрос занимает 800 мс.

Если изменить запрос с внутренним выбором пункта в результате выбора (который представляет собой одно число)

SELECT 
    contract.ctrId, 
    contract.ctrNr 
FROM 
    changeLog, 
    contract 
where 
    changelog.entid in (100000001611624);

Этого запрос занимает всего 16 мс.

Выполненный внутренний выбор занимает 4 мс.

Chnagelog.entid имеет индекс. Contract.ctris id - первичный ключ. Таблица контрактов имеет всего 2 строки, таблица изменений имеет около 40 тысяч.

Тем не менее, я действительно не могу обдумать это. В чем может быть проблема с выбором inners?

источник

2015-02-19 Szobi

Вы просматривали/сравнивали планы запросов? – jpmc26

Вопросы о производительности требуют правильной информации. Пожалуйста, ознакомьтесь с инструкциями в информации тега для [postgresql-performance]. –

Прежде чем беспокоиться о производительности, я думаю, вы должны исправить свой запрос. Вы не указали условие соединения, поэтому вы получаете декартовое соединение ... каждая запись в контракте соединяется с каждой записью в changeLog. Это не может быть большой проблемой в этом конкретном случае, поскольку контракт имеет только 2 записи, но в целом это плохая практика (если только это не преднамеренно). –

Извините за предоставленную информацию недостаточно, я уточню и последую за описанием тегов в следующий раз.

Объединение изменений и контракта не оказало большого влияния на производительность.

Проблема заключалась в том, что changelog является VIEW. Это объединение таблиц changelogActive и changelogPendig. Postgres необходимо было объединить две таблицы в представлении при каждом выборе.

Спасибо, ребята, все за подсказки, вы очень помогли!

источник

2015-02-19 11:45:52 Szobi

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

ответ

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