Спасибо! И сразу поправлю посыл: ide99 не только для админов — для разработки тоже (наверное даже для разработки в первую очередь).
Всё, что вы перечислили, уже есть: — SQL-редактор (Monaco): правка, мульти-курсор, форматирование; — подсветка синтаксиса PostgreSQL и PL/pgSQL; — автокомплит — таблицы, колонки, CTE, функции, JSONB-пути, плюс сниппеты.
Из PL/pgSQL пока не хватает автокомплита локальных переменных и параметров внутри тела функции (DECLARE … BEGIN) — это в планах. Всё остальное для разработки на месте уже сейчас.
спасибо — по вашему отчёту нашлись и поправлены сразу две вещи, обе в 1.0.7:
«Unhandled rejection» при подключении. На PostgreSQL 9.6 часть запросов к системному каталогу лезла в колонки, которых в 9.6 ещё нет (prokind, pg_sequences и пр.) — отсюда необработанная ошибка. Сделали совместимые версии запросов.
«В браузере БД только таблицы и вью». Та же причина: функции, процедуры и последовательности не подгружались из-за тех же запросов. Теперь на 9.6 они видны, как и в DBeaver.
Обновитесь до 1.0.7 (deb уже там). Если на 9.6 где-то ещё всплывёт странность — приложите, пожалуйста, свежий ide99.log.* из папки logs/ рядом с данными приложения: мы добавили нормальные файловые логи, по ним причина видна сразу.
Они там есть, просто сгруппированы внутри схемы, а не лежат в общем списке. Раскройте узел схемы (например, public) под Tables и Views будут отдельные группы Functions, Types, Sequences, Materialized Views. То есть путь такой: Schemas → public → Functions.
Если групп не видно - скорее всего дерево не обновилось после подключения, нажмите ⌘+R (или ↻ в шапке панели). Ещё момент: видно только то, на что у вашей роли есть права, так что функции в схеме, к которой нет доступа, не покажутся.
И лайфхак: в строке поиска над деревом префикс f: фильтрует только функции - f:jsonb_* найдёт всё, что начинается с jsonb_. Удобнее, чем листать.
Спасибо за репорт, без иронии - краш при коннекте это серьёзно. Заведите issue на гитхабе (или киньте сюда): ОС, как подключались (хост/порт, ssl), что в логе перед падением. Телеметрия у вас как раз не ушла, так что сам я этот краш не увижу, для диагностики нужны детали. И да, телеметрию можно выключить, если смущает.
Так скрипты и есть весь смысл статьи, забирайте, инструмент для этого не нужен, я об этом прямо в конце и написал. Что «любой дба помнит наизусть» - охотно верю, но на практике чаще queries.sqlоткрывают раз в квартал, когда уже горит. Тулза ровно чтобы не гонять это руками, не более.
Дебаг в планах есть. Трассировку параллельных вызовов отмечу отдельно - два pgadmin в двух браузерах боль знакомая, так что кейс понятный и нужный. Точных сроков пока не назову, но в бэклоге уже лежит. Как будет время, опишите пж свой сценарий чуть подробнее, что именно хотите видеть в трассировке, поможете с приоритетом.
Так и есть, выше в ветке про то же писал - cost_limit и воркеры в связке, иначе vacuum просто быстрее упрётся в лимит и так же спит. И scale_factor пер-таблично сверху, чтобы он вообще приходил раньше.
Ага, в одиночку cost_delay крутить смысла мало, вы правы, это пара. Грубо говря: throughput ≈ cost_limit / cost_delay, vacuum копит стоимость и засыпает на delay, когда упрётся в limit. Так что ниже 2 мс задержку я не трогаю (в ноль вообще нельзя диск ляжет), а поднимаю cost_limit: дефолтные 200 для SSD смешные, ставлю 1000–3000.
Только не наступите на грабли: cost_limit делится между воркерами. Накинуть max_workers, не подняв лимит, каждый станет медленнее, а не быстрее. И честно, для больших горячих таблиц сильнее всего бьёт не cost-тюнинг, а scale_factor пер-таблично, с 0.2 до 0.02–0.05. Cost заставляет vacuum работать быстрее, scale_factor - приходить раньше. И поставьте log_autovacuum_min_duration = 0, иначе крутите вслепую.
Так и есть, не спорю. Только про дефолтный cost_delay оговорюсь - это боль до 11-й версии, там 20 мс. С 12-й он уже 2 мс, с 14-й и page_miss опустили с 10 до 2, так что из коробки autovacuum давно не такой зажатый. У меня в корне кризиса на свежих версиях чаще не он, а scale_factor 0.2 на здоровенной таблице (vacuum приходит, когда дохлых строк уже миллионы) и cost_limit 200, который вообще из 2004 года. Ну и любимое, это висящая транзакция держит xmin, и тогда autovacuum хоть как разгоняй, мёртвые строки убрать не дадут.
Спасибо! И сразу поправлю посыл: ide99 не только для админов — для разработки тоже (наверное даже для разработки в первую очередь).
Всё, что вы перечислили, уже есть: — SQL-редактор (Monaco): правка, мульти-курсор, форматирование; — подсветка синтаксиса PostgreSQL и PL/pgSQL; — автокомплит — таблицы, колонки, CTE, функции, JSONB-пути, плюс сниппеты.
Из PL/pgSQL пока не хватает автокомплита локальных переменных и параметров внутри тела функции (
DECLARE … BEGIN) — это в планах. Всё остальное для разработки на месте уже сейчас.спасибо — по вашему отчёту нашлись и поправлены сразу две вещи, обе в 1.0.7:
«Unhandled rejection» при подключении. На PostgreSQL 9.6 часть запросов к системному каталогу лезла в колонки, которых в 9.6 ещё нет (
prokind,pg_sequencesи пр.) — отсюда необработанная ошибка. Сделали совместимые версии запросов.«В браузере БД только таблицы и вью». Та же причина: функции, процедуры и последовательности не подгружались из-за тех же запросов. Теперь на 9.6 они видны, как и в DBeaver.
Обновитесь до 1.0.7 (deb уже там). Если на 9.6 где-то ещё всплывёт странность — приложите, пожалуйста, свежий
ide99.log.*из папкиlogs/рядом с данными приложения: мы добавили нормальные файловые логи, по ним причина видна сразу.Они там есть, просто сгруппированы внутри схемы, а не лежат в общем списке. Раскройте узел схемы (например,
public) подTablesиViewsбудут отдельные группыFunctions,Types,Sequences,Materialized Views. То есть путь такой: Schemas → public → Functions.Если групп не видно - скорее всего дерево не обновилось после подключения, нажмите
⌘+R(или ↻ в шапке панели). Ещё момент: видно только то, на что у вашей роли есть права, так что функции в схеме, к которой нет доступа, не покажутся.И лайфхак: в строке поиска над деревом префикс
f:фильтрует только функции -f:jsonb_*найдёт всё, что начинается с jsonb_. Удобнее, чем листать.https://ide99.ru/docs/schema/schema-browser/
Так скрипты и есть весь смысл статьи, забирайте, инструмент для этого не нужен, я об этом прямо в конце и написал. Что «любой дба помнит наизусть» - охотно верю, но на практике чаще
queries.sqlоткрывают раз в квартал, когда уже горит. Тулза ровно чтобы не гонять это руками, не более.Дебаг в планах есть. Трассировку параллельных вызовов отмечу отдельно - два pgadmin в двух браузерах боль знакомая, так что кейс понятный и нужный. Точных сроков пока не назову, но в бэклоге уже лежит. Как будет время, опишите пж свой сценарий чуть подробнее, что именно хотите видеть в трассировке, поможете с приоритетом.
Так и есть, выше в ветке про то же писал -
cost_limitи воркеры в связке, иначе vacuum просто быстрее упрётся в лимит и так же спит. Иscale_factorпер-таблично сверху, чтобы он вообще приходил раньше.Спасибо! Если есть свои наработки в
queries.sql- кидайте, интересно глянуть.Ага, в одиночку
cost_delayкрутить смысла мало, вы правы, это пара. Грубо говря: throughput ≈cost_limit / cost_delay, vacuum копит стоимость и засыпает на delay, когда упрётся в limit. Так что ниже 2 мс задержку я не трогаю (в ноль вообще нельзя диск ляжет), а поднимаюcost_limit: дефолтные 200 для SSD смешные, ставлю 1000–3000.Только не наступите на грабли:
cost_limitделится между воркерами. Накинутьmax_workers, не подняв лимит, каждый станет медленнее, а не быстрее. И честно, для больших горячих таблиц сильнее всего бьёт не cost-тюнинг, аscale_factorпер-таблично, с 0.2 до 0.02–0.05. Cost заставляет vacuum работать быстрее, scale_factor - приходить раньше. И поставьтеlog_autovacuum_min_duration = 0, иначе крутите вслепую.Так и есть, не спорю. Только про дефолтный
cost_delayоговорюсь - это боль до 11-й версии, там 20 мс. С 12-й он уже 2 мс, с 14-й иpage_missопустили с 10 до 2, так что из коробки autovacuum давно не такой зажатый. У меня в корне кризиса на свежих версиях чаще не он, аscale_factor 0.2на здоровенной таблице (vacuum приходит, когда дохлых строк уже миллионы) иcost_limit 200, который вообще из 2004 года. Ну и любимое, это висящая транзакция держит xmin, и тогда autovacuum хоть как разгоняй, мёртвые строки убрать не дадут.