DataGrip потаблично можно, навикат не пробовал, сейчас гляну

в DataGrip есть встроенный инструмент... равно как и в NaviCat'e. Это если из гуидин, а не обособленных решений.

как?

вариантов в гугле море :) интересует кто что исползьует, чтоб наверняка

DataGrip потаблично можно, навикат не пробовал, сейчас гляну

все диффы можно вывести одним скопом скриптов, предварительно выбрав что и куда надо мигрировать

Я года полтора пользуюсь pyrseas. http://pyrseas.readthedocs.io/en/latest/index.html

ох :) попробую разобраться. спасибо

как?

как это делать?) в Датагрипе выделить 2 схемы и нажать Ctrl + D

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

как это делать?) в Датагрипе выделить 2 схемы и нажать Ctrl + D

wow! 10x

как это делать?) в Датагрипе выделить 2 схемы и нажать Ctrl + D

работает ! спасибо

Всем доброго утра. С недавних пор начала возникать проблема обрыва стрима (VCLib.Common.ProcessException: Ошибка исполнения на сервере ---> VCLib.Common.ProcessException: Ошибка работы с базой данныхException while reading from stream в Npgsql.ReadBuffer.Ensure(Int32 count, Boolean dontBreakOnTimeouts) в Npgsql.NpgsqlConnector.DoReadMessage(DataRowLoadingMode dataRowLoadingMode, Boolean isPrependedMessage) в Npgsql.NpgsqlConnector.ReadMessageWithPrepended(DataRowLoadingMode dataRowLoadingMode) в Npgsql.NpgsqlConnector.ReadExpecting[T]() в Npgsql.NpgsqlDataReader.NextResultInternal() в Npgsql.NpgsqlDataReader.NextResult() в Npgsql.NpgsqlCommand.Execute(CommandBehavior behavior) в Npgsql.NpgsqlCommand.ExecuteDbDataReaderInternal(CommandBehavior behavior) в Npgsql.NpgsqlCommand.ExecuteDbDataReader(CommandBehavior behavior) в System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader() ) в начале грешил на запрос, но ошибка начала валится совсем в разных запросах, вопрос. могут ли влиять какие то настройки постгреса на возникновение данной ошибки

Доброго времени суток , есть SELECT который с ORDER BY выполняется очень долго без него быстро, помогите пожалуйста оптимизировать его. Индексы стоят на поля. Выборка : https://pastebin.com/UWNrxgc9 План с ORDER BY : https://pastebin.com/jeERrwSg План без ORDER BY : https://pastebin.com/5mbuS6rN MAX длина ss.name : 26 , rp.name(80)

Планы, конечно, удобнее в https://explain.depesz.com/ смотреть.

А индексы какие именно?

У вас всё время просто сортировка занимает, потому и долго. Нужен упорядоченный индекс. Можно ещё данные кластеризовать по индексу в таблице, будет ещё быстрее. https://www.postgresql.org/docs/9.6/static/indexes-ordering.html

Попробуйте NULLS LAST добавить к запросу.

перезалил план 1 : https://explain.depesz.com/s/KVxj план 2 : https://explain.depesz.com/s/I2C

я забыл уточнить что inno_paymentreport VIEW но выборка оттуда быстрая

попробую index переделать на NULL LAST

Он по умолчанию такой.

Что у вас за машина? У вас 20 тысяч строк в памяти 30 секунд сортируются. Что-то долго.

top - 12:42:41 up 4 days, 3:34, 3 users, load average: 1.76, 1.33, 1.16 Tasks: 333 total, 2 running, 331 sleeping, 0 stopped, 0 zombie Cpu(s): 8.4%us, 0.1%sy, 0.0%ni, 90.6%id, 0.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 22538748k total, 18590524k used, 3948224k free, 554668k buffers Swap: 8388600k total, 32152k used, 8356448k free, 14529780k cached

Версия постгреса : 9.2 ,OS CentOS 6.5

а можно \d res_partner и \d sale_shop ?

https://pastebin.com/W0ipnL2N

У меня часто бывают проблемы с ORDER BY по таблице res_partner, например ORDER BY name или ORDER BY display_name

и inno_paymentreport тоже посмотреть можно?

там VIEW но выборка быстрая

а сколько строк во вьюхе?

288230

work_mem = 128MB shared_buffer = 3GB effective_cashe_size = 16GB autovacuum настроен

смотрите, первое соображение, которое приходит - это использовать покрывающие индексы хотя бы в таблицах res_partner и sale_shop, чтобы не ходить их них в саму таблицу. для (id, name), чтобы за name не лезть в таблицу, в res_partner (id, date, name)

опечалатся, в sale_shop создать идекс (id, name), в res_partner - (id, date, name).и посмотреть, изменится ли скорость

попробую

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

поле day которое используется для between не находится в res_partner, он из другой таблицы с VIEW

А по полю date из res_partner фильтрацию можно осуществить в запросе? Чем меньше данных мы поднимем с диска, теп быстрее будет запрос

Там в res_partner три поля типа bytea ещё.

Хотя сама таблица небольшая.

вроде же их не возвращает запрос, так что лежат и лежат себе в куче

Denis к сожалению не можем

ну ок, тогда выкидываем из покрывающего индекса дату и пробуем взлететь хотя бы с именами

я попробовал без date все равно грустно

мб work_mem добавитЬ , но думаю он и так норм 128MB

печаль, надо думать дальше, как уменьшить объем поднимаемых данных с диска и как бы индексы по-активнее попользвать

без order by за 2 сек выполняется

ну да, тогда к запросу самому вопросов нет. и индекс мы тоже не сможем использовать - сортировка по полям из двух разных таблиц

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

вот ему и плохо

попробую , спасибо за идею

убрал Bytea поля на тестовой базе с res_partner запрос выполняется 2x быстрее ,но все равно медленно 13973 ms

попробовад с res_partner выбрать только те поля которые мне нужно тоже нету профита select ss.name,rp.name,sum(partner_payed) as partner_payed,sum(cash_patient) as cash, sum(chg_patient) as chg, sum(transfer_patient) as transfer,sum(card_patient) as card,sum(cash_amount) as cash_amount from inno_paymentreport ip inner join (select id,name from res_partner) rp on rp.id=ip.partner_id inner join sale_shop as ss on ip.shop_id=ss.id where day between '2017-01-01' and '2017-04-05' group by ss.name,rp.name order by ss.name,rp.name

если только order by ss.name оставить тоже нету профита (в таблице ss 8 записей )

А можно explain analyze?

https://explain.depesz.com/s/2BDN

от запроса который написал выше

Он те же 34 секунды сортирует при новом запросе. Мда

этот запрос с реальной базы там есть bytea поля , дать с тестовой где их нет ?

ERROR: S client not available

этот запрос с реальной базы там есть bytea поля , дать с тестовой где их нет ?

Да

https://explain.depesz.com/s/t9Lp

with found_data as ( select ss.name as ss_name,rp.name as rp_name,sum(partner_payed) as partner_payed,sum(cash_patient) as cash, sum(chg_patient) as chg, sum(transfer_patient) as transfer,sum(card_patient) as card,sum(cash_amount) as cash_amount from inno_paymentreport ip inner join (select id,name from res_partner) rp on rp.id=ip.partner_id inner join sale_shop as ss on ip.shop_id=ss.id where day between '2017-01-01' and '2017-04-05' group by ss.name,rp.name ) select * from found_data order by ss_name, rp_name

вот такой запрос сколько?

"Total runtime: 8960.856 ms"

То есть 9 секунд. Выходит, тупит именно постгрес, подставляя в сортировку строки излишней длины

да , ORDER BY со стрингами он часто тупит

мб что-нибудь изменилось в 9,6? нужно обновиться

Ему всё равно, строки или нет, если по индексу сортировать.

Мне кажется, причина в том, что таблица широкая просто.

Попробуйте кластиризовать по индексу.

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

https://www.postgresql.org/docs/current/static/sql-cluster.html

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

Беда.

да и кластеризация только ускорит sequence scan, а у него проблема, что в памяти слишком широкая таблица лежит, ее тяжело вращать

collate c можно попробовать, если логика текстовой сортировки позволяет

есть хитрый план на грани фола. можно dyfxfkt отсортировать объединение res_partner и sale_shop, а птом к результату приджойнить inno_paymentreport, но тут есть опасность. стандарт sql не гарантирует, что при таком кейсе она 100% придет отсортированным

materialized view не поможет в вашем случае?

но вообще-то что не так не в запросе, а в способе хранения данных

по-хорошему вам там вообще непонятно зачем такая сортировка и группировка. логичнее выглядело бы два разных запроса

либо union

@jin2red materialized view не можем использовать версия 9.2. Будем обновляться в ближайщее время . Кстати 9.6 уже актуальна или на 9.5 обновиться ?

у нас в бою PostgreSQL 9.6.2

у нас в бою PostgreSQL 9.6.2

Сколько транзакций в пике ? Стабильна ?

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

@jin2red materialized view не можем использовать версия 9.2. Будем обновляться в ближайщее время . Кстати 9.6 уже актуальна или на 9.5 обновиться ?

Materialized view тут не помогут. У вас запрос без сортировки выполняется 2 секунды, если добавить order by, то 33. Проблем две. Первая, в плане запроса вначале все строки из inno_paymentreport с приджойненными двумя таблица вначале сортируется, потом только группируется. Сортировать приходится слишком много. Эта проблема решается через модификацию запроса, как я скинул с cte. Он выполняется уже 9 секунд. Значит, 7 секунд 30 тыс строк сортируются в памяти. Единственный вариант их ускорить - это уменьшить их энтропию. Я предлагаю пересоздать представление inno_paymentreport с сортировкой по shop_id и partner_id

там есть куда воткнуть два order by?

чтобы второй раз сортировать уже скорее-всего-сортированное