6Гб и запросы выполняются минутами? Самая лучшая рекомендация - рефакторинг схемы и запросов, остальное - временное и симптоматическое лечение

спасибо - по этому пути и идем. Но еще волнует вопрос нормально ли держать на одном инстансе 80 баз к которым подключается 3-4 человека к каждой базе из клиента.

только через эксперимент вопрос можно разрешить. 5 евро, Карл!

и то почасовая оплата

А как у вас производится подключение к базам? Напрямую/каждая база-свой балансировщик/общий балансировщик для всех баз?

Напрямую

только через эксперимент вопрос можно разрешить. 5 евро, Карл!

с удовольсвием - но я не админ - а разработчик - у нас админы на фрилансе все очень медленно - собираю инфу пока чтобы вынести на обсуждение в команде и порешить эту проблему. Могу сказать что в локальном окружении - запросы тоже медленно выполняются (есть просто банально кривые и проблемные) - при том что я конекчусь только к одной базе и у меня быстрый компьютер) Но кроме как пофиксить эти запросы хочется разобраться в архитектуре и сделать ее оптимальной.

что-то вспоминается дедушка Крылов )

А как вы бэкапите большие бд?

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

А как вы бэкапите большие бд?

насколько большие?

насколько большие?

5-15тб

наверно только через файловый бэкап всего кластера, но пусть лучше скажут знающие люди %)

что-то вспоминается дедушка Крылов )

зачем же так категорично.)

зачем же так категорично.)

аллегорично всего-лишь :-р >кроме как пофиксить эти запросы отсюда и начни

не более одного шага за один раз(с)дао программиста

Спасибо) Я еще вернусь.

ну конечно)) 1 мс

упс, to '1s';

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

Спасибо, да еще думаю чтобы тяжелые отчеты вынести при помощи репликации на другой инстанс.

другое дело)

Спасибо, да еще думаю чтобы тяжелые отчеты вынести при помощи репликации на другой инстанс.

Никак статистика какая? Переделывать архитектуру приложения - единственный верный путь в подавляющем большинстве случаев. Но надо смотреть.

для постгиса нужны иксы?

чет он сильно много пакетов требует (убунта)

сомнительно

для постгиса нужны иксы?

в клеточном ядре)

чет он сильно много пакетов требует (убунта)

скорее всего не только постгис ставишь. не осм случаем рендерить собираешься? ?

геосервер чтоб поднять)

ну там понятно что иксы нужны, на экран то намазывать

чет он сильно много пакетов требует (убунта)

ты можешь поучаствовать финансово в осуществлении https://github.com/Oslandia/SFCGAL/issues/136

тогда от постгиса отвалится 600 метров зависимостей

Ребят. Есть таблица. В ней есть 2 поля int. По этим двум полям сделан составной кластеризиванный btree индекс. При селекте в WHERE я эти два поля указываю, но Eplain почему-то seq scan показывает... Куда капнуть?

@dmitriy_vasilyev покажи explain

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

explain analyze select * from flowlog where timestart > 0 AND timeend = 0

это запросик

записей попадающих под условие ~200

analyze таблице после cluster делал?

записей попадающих под условие ~200

их 479

да, вижу :)

analyze таблице после cluster делал?

не делал

сделал кластер и аналайз

Не помогло

Коллеги, а кто может по планировщику запроса подсказать ? почитал у пгпро, они тестировали на 366+ партициях и 140 пользователях и данные были более менее вменяемые, даже без оптимизаций. Сегодня ночью пришел мега софт и сейчас имеем картину когда на планирование вставки в таблицу с 1200 партициями уходит 2500 мс и кушается 600 метров памяти

парень из postgrespro говорил, что over 100 партиций уже плохо

К моему сабжу. Create-код индекса CREATE INDEX "timeIndex" ON public.flowlog USING btree (timestart, timeend); ALTER TABLE public.flowlog CLUSTER ON "timeIndex";

Не помогло

Vacuum freeze вам поможет, у вас не обновлена карта видимости

Vacuum freeze вам поможет, у вас не обновлена карта видимости

не помогло

табличка пока маленькая, все выполняется быстро. Но кода в продакшн пойдет, то сильно распухнет

А покажите план после заморозки

Нет, ну может, конечно, планировщик считает, что без индекса дешевле... а попробуйте выставить enable_seqscan=off и посмотрите время запроса через индекс

А сколько строк сейчас в таблице? Не получается так что из-за малого их числа планировщик решает, что seqscan будет быстрее?

По плану выдаёт 475, а отбросило 252261

251602

Хммм... выключайте секскан и план запроса в студию)

enable_seqscan=off - это не понял где сделать

в конфигу нельзя субд в продакшене

я себе базу отдельную просто сделал

Не, это в сессии

Ребят. Есть таблица. В ней есть 2 поля int. По этим двум полям сделан составной кластеризиванный btree индекс. При селекте в WHERE я эти два поля указываю, но Eplain почему-то seq scan показывает... Куда капнуть?

а что значит кластеризированный? это фантастика, нету в pg кластеризированных индексов :)

ALTER TABLE public.flowlog CLUSTER ON "timeIndex";

и че, это до первого апдейта

я не апдейтю поля

а что значит кластеризированный? это фантастика, нету в pg кластеризированных индексов :)

Не фантастика. Кластеризация - разовая операция, когда строки физически перекладываются в соответствие с индексом. Разово!

я не апдейтю поля

а вакуум так не считает :)

который проставляет там всякие hint bits

ERROR: S client not available

у меня insert/delete only

у меня insert/delete only

delete по физике это часть операции update :)

enable_seqscan=off - это не понял где сделать

В psql напишите set enable_seqscan=off и в данной сессии у вас не будет использоваться сканирование

Ну и посмотрим время выполнения в таком режиме. И план

В psql напишите set enable_seqscan=off и в данной сессии у вас не будет использоваться сканирование

Сделал

Так. А индекс у вас есть? Покажите \d таблица

set enable_seqscan=off; explain analyze select * from flowlog where timestart > 0 and timeend = 0;

А, ок. Индекс есть)

Вообще очень странно, почему планировщик сам не использует индекс

А покажите индекс

Я думаю, у вас порядок колонок не верный

Denis https://www.postgresql.org/docs/9.6/static/release-9-6-3.html

"Fix possible crash when rescanning a nearest-neighbor index-only scan on a GiST index (Tom Lane)"

К моему сабжу. Create-код индекса CREATE INDEX "timeIndex" ON public.flowlog USING btree (timestart, timeend); ALTER TABLE public.flowlog CLUSTER ON "timeIndex";

А кто из Dmitriy Vail'ev и Dmitriy Vail'ev бот а кто человек?

это про тот баг зарепорченный?

А кто из Dmitriy Vail'ev и Dmitriy Vail'ev бот а кто человек?

я человек)

К моему сабжу. Create-код индекса CREATE INDEX "timeIndex" ON public.flowlog USING btree (timestart, timeend); ALTER TABLE public.flowlog CLUSTER ON "timeIndex";

Поменяйте колонки местами и попробуйте без выключениям секскана

Я менял, результат одинаковый

последовательность такая везде: в таблице, в индексе и запросе

CREATE TABLE public.flowlog ( timestart integer, timeend integer,

Я менял, результат одинаковый

в индексе поменяйте))

у вас в начале строгий отбор, потом условие больше. конечно оно по индексу иначе не будет работать

"Fix possible crash when rescanning a nearest-neighbor index-only scan on a GiST index (Tom Lane)"

похоже, это оно. но мне в рассылку письмо о закрытии бага не пришло

https://www.postgresql.org/search/?m=1&l=8&q=14641

у вас в начале строгий отбор, потом условие больше. конечно оно по индексу иначе не будет работать

В индексе нужно поменять местами поля?

Ну конечно. Говорите drop index timeindex , а потом create index timeindex on flowlog (timeend, timestart)

Но смысла я до конца так и непонял

Если не сложно, подробнее

Поверьте, он есть? прочитайте http://use-the-index-luke.com/sql/anatomy/the-leaf-nodes , там все понятно