Добрый день всем.

Собственно сабж
др.тулы предложить конечно можно
(а если отедльные для сравнения планов в вебе так вообще отлично)

Но я сильно ограничен на рабочем компе полиси конторы где я работаю
(DataGrip я ставли а месяц посмотреть )

Maxim Boguk,

В идеале хотелось бы что-то похожее
https://www.sentryone.com/plan-explorer
с крамными квдаратиками

Да фактически 2 плана сравнивать не часто приходится
скорей смотреть где могут быть проблемы

ps Спасибо за ссылку посмотрю

а фиг
оказыается в deveaver
план запроса НЕ КОПИРУЕТСЯ !!!
ТОЛЬКО ячейка : Index Scan

Мда ..
тул вроде неплхой но такие вещи убивают

Misha111, Да СПС
explain позволяет вывести в текстовый файл а дальше да можно сравнивать (я notepad++)

м.б кто подскажет я смигрировал с Оракла среднюю БД в Postgres Azure (10)
( 7 789 241 - count самой большой таблицы ) и имею очень большие проблемы с перфомансом
для теста миграции сделал проверку count всех таблиц
SELECT 'table1' , COUNT(*) FROM table1 UNION ALL ... table2 , ... tableN

запрос в Оракле 12 выполянется - 10 секунд
в Postgres Azure :
1 раз : 17 min 333 sec !
2 : 1 min 10 sec
3 : 17.7 sec

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

Взял самую большую таблицу SELECT 'table1' , COUNT(*)
в Оракле - 0.3 сек.
в Постгрес 1 раз : 50+ сек

Finalize Aggregate (cost=9307.78..9307.79 rows=1 width=40)
-> Gather (cost=9307.56..9307.77 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=8307.56..8307.57 rows=1 width=8)
-> Parallel Seq Scan on partneraddressid (cost=0.00..7786.65 rows=208365 width=0)

Ну и чего тут можно улучшить то в этом плане ?

Maxim Boguk,
Azure это моя данность и это не обсуждается (Не мой выбор - заказчика)
да и Оракл там необычный в DBaas (частном облаке) - однако ж вполне быстро.

PS Ну попроюу тупо дозаказать ресурсов
пока был Basic

за explain(analyze,buffers,timing) СПАСИБО

Параметры сервера я могу посмотреть AZURE в браузере
и даже поменяь на DEV без проблем

тут вопрос куда и на Какие параметры смотреть
(т.е я уже там лазил даже читал по некоторым описание
force_parallel_mode = OFF
)
ссылки приветсвтуются

На данный момент пока проблема в Seelct
до I/U/D операций даже не дошло (данные загрзуились черзе ora2pg и все - лежит фактически снапшот
толок изредка перегружаю отдельные таблицы )

СПС за ссылку
познавательно
и я в ПРИНЦИПЕ СОГЛАСЕН
реально мне надо будет N раз после полного импорта черзе ora2pg проверить каунты с ораклом
ну там и ок - я подожду 20-30 мин хоть

но проблема не только в этом же
есть 70+ вьюх только на одной схеме к-ю я сейчас симпоритровал в постгрес
(примерно половину из них пришлось фиксить из за не поддерижвающихся фич оракла)
и вот я начинаю проверять эти вьюхи - ну а как по даннным то ?
и логично ведь проверить для первоначального теста
SELECT COUNT(*) FROM - и тут я получаю дикие тормоза в постгрес.

пытаюсь проверить тода на небольших датасетах
SELECT * FROM View1 where id1 = <> ;
где то работате более менее сопоставимо с Ораклом (т.е медленней но не намного )
а где то катастрофически медленней

и проверять каждую вьюху пока НЕ вариант (у меня есть где то 10 критичных пока на них )
причем там есть вьюхи разного назначения
часть для экспорта-импорта в систему и тут тормоза сильно мешают при проверке (но возможно будут не так критичны)
но большАя часть исполюзуется для backend
и вот тут разница между 1 сек в оракле и 30 в постгрес это уже проблема.

Maxim Boguk,
да я согласен
вот про настройки БД и хотелось бы почитать что-то толковое для начала типа бест-практис
(в идеале конечно для ажура - но пойдет и обычное)
понятно что все оисания есть в доке

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