Можно сказать люто-бешеная аналитика.

Ну как бе по 6 таблицам сверка (selectы), потом получение нужных id, парсинг строк и их разбор, и инсерт записи с уже готовой информацией

Самая большая база 50кк записей без индекса

отменяй и иди переписывать

с эксплейнами и нотисами

Ок

https://gist.github.com/Komzpa/69fa1b7149f48e447c634b4bf171f1ce

Вопрос, как узнать сколько в транзакции добавилось строк?

https://dba.stackexchange.com/questions/123145/how-to-view-tuples-changed-in-a-postgresql-transaction

вообще, 85 гигов вот сексканом прошлись за 463 секунды

так что если что и тормозит, то дополнительная логика

Таблица не в локе случайно ? может твой апдейт ждет чего то ?

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

Таблица не в локе случайно ? может твой апдейт ждет чего то ?

ничего не ждет. Все последобвательно работает.. Просто есть Like, просто есть join, просто все меделнно, просто без хранимок (все запросы от бэкенда) И если сейчас скажете про индексы и то, что join и like юзать плохо, и то, что хранимки надо юзать я пойду и повешусь ибо сам это зною, но в рамках задачи ничего поделать не могу (потом этот же скрипт на продакшне надо будет применить)

https://dba.stackexchange.com/questions/123145/how-to-view-tuples-changed-in-a-postgresql-transaction

Спасибо

ничего не ждет. Все последобвательно работает.. Просто есть Like, просто есть join, просто все меделнно, просто без хранимок (все запросы от бэкенда) И если сейчас скажете про индексы и то, что join и like юзать плохо, и то, что хранимки надо юзать я пойду и повешусь ибо сам это зною, но в рамках задачи ничего поделать не могу (потом этот же скрипт на продакшне надо будет применить)

Есть do

Я сейчас вопрос задаю про nextval специально, потому что доверять ли втроенному инструменту laravel 5 по модификации таблиц или запросом фигачить?

Насколько адекватно то ,что он не переименовал default в serial поле?

То есть вопрос даже не о фреймворке, а о том "менять ли nextval при переименовании таблицы?"

Есть do

Понял, спасибо

Насколько адекватно то ,что он не переименовал default в serial поле?

У sequence есть доп. свойство OWNED BY, в котором указан столбец таблицы. Вот это главное, на что надо обращать внимание. Если owned by есть (а он есть, когда говорим "serial" при создании таблицы), при переименовании всё будет ок, секвенс будет "принадлежать" тому же столбцу. Резюме: На serial не надо внимания обращать при проверках, надо смотреть owned by у сиквенса

а у меня 1с с базой в десяточке завелась ?

Что завелась - не неожиданно. Попробуйте сравнить лительность расчета увольнения в ЗУП, если не лень и есть тесткейс. У меня все руки не доходят.

ну я же её в продакш не пихаю, так только тестовая база... да еще и постргес собрал с включенным дебагом. Тест Гилева показал чуть меньше чем на 9.6 с аналогичным конфигом на той же железяке, хотя это слабый показатель....

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

ну я же её в продакш не пихаю, так только тестовая база... да еще и постргес собрал с включенным дебагом. Тест Гилева показал чуть меньше чем на 9.6 с аналогичным конфигом на той же железяке, хотя это слабый показатель....

Показатели теста Гилева имеют отношение к реальной производительности многопользовательской системы чуть менее, чем никакое.

ну я же её в продакш не пихаю, так только тестовая база... да еще и постргес собрал с включенным дебагом. Тест Гилева показал чуть меньше чем на 9.6 с аналогичным конфигом на той же железяке, хотя это слабый показатель....

меньше, чем дебаг-сборка 9.6?

вообще, если дебаг-сборка становится медленнее, это может говорить, что в ней стало больше дебаг-сообщений и ассертов, что скорее хорошо :)

Как срастить разбитые на части таблицы?

в фиас это addrobj01, addrobj02 и т.д.

Ну дико же. Всего по 300к записей, и писать теперь ради этого джойны

Понимаю что это партицированные таблицы. Но при импорте это просто таблицы без какких либо связей.

а как связаны импорт и джоины?

вообще не совсем понятно, с каого боку тут джоины?

а как связаны импорт и джоины?

извиняюсь, юнионы

тем более не понятно

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

SELECT * (SELECT * FROM house01 UNION SELECT * FROM house02 UNION SELECT * FROM house03) where ...

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

партиции фиаса через pgdbf приходят как обычные таблицы

а, вот теперь объяснили.

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

Можно как вариант конечно еще их в одну таблицу перемещать, написав процедуру, но может есть решение проще?

а не имеет ли смысл импортировать эти данные в "свою" структуру?

ну в самом-самом крайнем случае нечто типа create table house00 as (SELECT * FROM house01 UNION SELECT * FROM house02 UNION SELECT * FROM house03) и потом уже работать с house0

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

Я думал может есть хитрая процедура для сбора таблиц в 1 партицированный массив

Ну или хотябы как применить INHERITS к существующим таблицам?

Согласно доке самый простой путь - это написать: ALTER TABLE house01 INHERIT house; Но тогда надо обёртывать в for Жаль нет процедуры готовой типа: inherit_tables('house','house*')

не думай процедурами

набор текста ALTER TABLE house01 INHERIT house; легко получить конкатенациями названий таблиц, и потом пайпом загнать в psql

как-нибудь вроде \copy (select 'alter table '|| table_name || ' inherit house;' from information_schema.tables where table_name like 'house%')

через полгода выйдет апдейт, будешь накатывать и забудешь в итераторе циферку поправить

в жизнь потом не отыщешь, отчего у тебя дома не находятся

согласен. Жаль что эта собака всегда ращбитые табилцы грузит. Но твой select лучше применим. думал об этом. Не знал как написать.

А почему copy?

Это же копирование данных

чтобы без рамочек и лишнего эскейпинга в консоль рисовалось

ааа!

оно так легко разворачивается в psql -c "\copy (select 'alter table '|| table_name || ' inherit house;' from information_schema.tables where table_name like 'house%') to stdout" | psql

ERROR: S client not available

я конечно план по 40 млн записей не делаю, но судя по всему на каждую дочернюю таблицу нужен индекс. Потому что ооочень долго записи отбирает. При этом активно винт жрёт

я конечно план по 40 млн записей не делаю, но судя по всему на каждую дочернюю таблицу нужен индекс. Потому что ооочень долго записи отбирает. При этом активно винт жрёт

Я правильно понял, что у вас wildcard поиск по куче таблиц адресов и оно тормозит? Если так, вы создавали индекс gin с классом pg_trgm_ops в таблицах?

Вайлдкард не знаю что такое, в varchar стандартный индекс, верно

Wildcard - это поиск типа like '%...%' по текстовому полю. Оно?

Если оно, то обычный b-tree бесполезен, нужны триграммы. Их я и посоветовал

Здравствуйте, можно ли посчитать количество записей, например: select * from table where id=198 выведет соответственно запись где id=198 А можно ли вывести количество записей перед 198 записью?

select count(1) from table where id < 198; ?

партиции фиаса через pgdbf приходят как обычные таблицы

это не партиции. а таблицы честные. разбитые по регионам.

не думаю что Вам нужен поиск по всем регионам сразу.

select count(1) from table where id < 198; ?

спасибо, а можно добавить к основному запросу select * from table where id=198

нечто подобное нужно select * from j_patient where id = 150 union ALL select count(id) FROM j_patient where id < 150 order by id

нечто подобное нужно select * from j_patient where id = 150 union ALL select count(id) FROM j_patient where id < 150 order by id

Ммм.... первая часть возвращает вам строку из нескольких колонок, где id =150, а вторая - колонку count с одной строкой. Это бессмысленно, что вы хотите получить по итогу?

Я понимаю что количество колонок в запросе должно быть ровно... В итоге нужно одним запросом вывести и все записи и count до id в условии

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

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

посмотрите https://www.postgresql.org/docs/current/static/functions-json.html , особенно функцию jsonb_build_object - все можно одним запросом собрать

Я понимаю что количество колонок в запросе должно быть ровно... В итоге нужно одним запросом вывести и все записи и count до id в условии

Совет выше какой-то логический бред. То что вы хотите решается оконными функциями

Например так: select *, count(*) over (partition by id) from table where id = 198;

Например так: select *, count(*) over (partition by id) from table where id = 198;

а зачем вы окно сделали по id? в каждом окне будет одна единственная запись. тут скорее select *, (select count(*) from j_patient where id < 150) as num from table where id = 150;

а зачем вы окно сделали по id? в каждом окне будет одна единственная запись. тут скорее select *, (select count(*) from j_patient where id < 150) as num from table where id = 150;

Да, все верно, ваш вариант лучше. ??

а зачем вы окно сделали по id? в каждом окне будет одна единственная запись. тут скорее select *, (select count(*) from j_patient where id < 150) as num from table where id = 150;

спасибо

Например так: select *, count(*) over (partition by id) from table where id = 198;

спасибо

не думаю что Вам нужен поиск по всем регионам сразу.

Блин, в доке нигде не увидел. Может пропустил

Получется если мне нужен 16 регион, беру таблицу house16

Блин, в доке нигде не увидел. Может пропустил

в доке фиаса

Получется если мне нужен 16 регион, беру таблицу house16

именно.

с...ка (прошу прощения за эмоции), это же я вчера зря отбор делал еще по почти 90 таблицам! С другой стороны практика в написании SQL запросов

с...ка (прошу прощения за эмоции), это же я вчера зря отбор делал еще по почти 90 таблицам! С другой стороны практика в написании SQL запросов

А как время выполнения сократится )

Ну это вообще неоспоримо :)

то ли 40млн записей, то ли 300тыс