Очень интересно, а RuntimeAppend получается не видно через EXPLAIN ANALYZE? или нужно его специально включать?

Он включен по умолчанию, и его видно в explain

При explain analyze он выводит только те партиции, которые были прочитаны

Посмотрите readme, там есть примеры плана

Спасибо

Всем привет. Подскажите есть для PostgreSQL внемяемый dashboard , пофункционалу похожий на Oracle EM ?

o_O на дедики иксы ставить и цеплятся по vnc? порноолимпиада среди нешколоты

Мы же про запуск pgadmin правда? И про работу на машине админа и пр .

Я еще про ssh-туннели знаю. Что не отменят того факта, что на всякое хитрое отверстие найдётся кол с винтом. А на кол с винтом найдется отверстие с лабиринтом. А собранная на плюгинах vim-оболочка - её в куда угодно протащить можно. за исключением случаев, когда какое-нибудь нано является редактором по-умолчанию, а наличие других зарублено на корню службой безопасности

По-моему давно же известно что pgadmin может не только к localhost коннектится. Мы же не об этом , правда?

Всем привет. Подскажите есть для PostgreSQL внемяемый dashboard , пофункционалу похожий на Oracle EM ?

Нету

Мы же про запуск pgadmin правда? И про работу на машине админа и пр .

Нет, я про работу с удалённой БД, к которой доступ есть только по через ssh.

Нету

прямо печаль - беда.

прямо печаль - беда.

Дешборд для чего надо? Поссотреть там cpu память кеши и пр?

Дешборд для чего надо? Поссотреть там cpu память кеши и пр?

ага, медленые запросы, планы их. состояние сервера БД ну и да , кэши всякие, использование индексов...

Нет, я про работу с удалённой БД, к которой доступ есть только по через ssh.

Ssh тунель? Datagrip позволяет из коропки. Зачем X?

ага, медленые запросы, планы их. состояние сервера БД ну и да , кэши всякие, использование индексов...

pg_top норм ?

правда я подозреваю что каждый пилит свой велосипед

ага, медленые запросы, планы их. состояние сервера БД ну и да , кэши всякие, использование индексов...

Такой роскоши пока нет. Если только анализ log файлов посредством pgbadger. В реальном времени есть агент mamonsu для zabbix

есть ещё okmeter :)

А я свои скрипты для кактуса и нагиоса писал в свое время на перле...

в том и дело что много разных утилит или плагинов, но что тотакое ввиде более менеее законченного продукта нету.

после использования Oracle EM прям печаль

после использования Oracle EM прям печаль

а у EnterpriseDB же был какой-то свой EM

а у EnterpriseDB же был какой-то свой EM

но оно платное. :(

а, надо крутой enterprise, но чтобы нахаляву

но оно платное. :(

https://blog.dbi-services.com/em13c-and-postgres-plugin/

https://blog.dbi-services.com/em13c-and-postgres-plugin/

интрересненько. нужно будет почитать

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

хотя триал дают, скачайте, потыкайте

а у EnterpriseDB же был какой-то свой EM

На основе пгадмина

серьёзно? мда

А откуда им годную основу то то взять. Не придумано еще ничего лучше.

MySQL Enteprise Manager написан с нуля. правда его пишут года так с 2005-го

хотя триал дают, скачайте, потыкайте

что то я не нашел там ссылку. нашел только плагин для newrelic. Если можете скиньте линк

щаа

что то я не нашел там ссылку. нашел только плагин для newrelic. Если можете скиньте линк

вот как устанавливать

https://bluemedora.com/guide-to-installing-oracle-em-plugin-for-postgresql/

а вот запрос на демку

https://bluemedora.com/request-form/

и краткая презенташка

https://bluemedora.com/wp-content/uploads/2016/10/Plugin-PostreSQL-Nov-2017.pdf

https://bluemedora.com/wp-content/uploads/2016/10/Plugin-PostreSQL-Nov-2017.pdf

интересно как они высчитывают statement hash https://i.imgur.com/2GxpXsQ.png

вообщем хотел проконсультроваться. хочется хранить метрики в postgresql, у метрики кроме ключа есть tags в виде: k1=v1, k2=v2. хотел посоветоваться в каком виде лучше хранить tags в postgresql

в основном запросы без участия tags, но некоторые запросы будут такого плана: sum() group by tags where tags.k1= 'key1' avg(), tags.value group by tags where tags.k1 = 'key1'

Селективные условия?

храни в кликхаусе

у меня глупый вопрос помогите разобраться: ` SELECT month_d as date, AVG (extract(day from pmo._days.month_d::timestamp - bench_assignments.startdate::timestamp )) as "BAD", COUNT ( ??? ) as "Employee" FROM pmo._days join bench_assignments..... ...... .... ` я могу в count вставить запрос тот что чтобы пощитать количество людей к определеной дате ? SELECT * FROM pmo.assignment WHERE pmo.assignment.billable_status_id IN ( 2, 4 ) AND month_d BETWEEN pmo.assignment.startdate AND pmo.assignment.finishdate

в основном запросы без участия tags, но некоторые запросы будут такого плана: sum() group by tags where tags.k1= 'key1' avg(), tags.value group by tags where tags.k1 = 'key1'

Так у Вас уже есть какая-то структура (можете показать)?

храни в кликхаусе

самый простой и скучный ответ :)

у меня глупый вопрос помогите разобраться: ` SELECT month_d as date, AVG (extract(day from pmo._days.month_d::timestamp - bench_assignments.startdate::timestamp )) as "BAD", COUNT ( ??? ) as "Employee" FROM pmo._days join bench_assignments..... ...... .... ` я могу в count вставить запрос тот что чтобы пощитать количество людей к определеной дате ? SELECT * FROM pmo.assignment WHERE pmo.assignment.billable_status_id IN ( 2, 4 ) AND month_d BETWEEN pmo.assignment.startdate AND pmo.assignment.finishdate

Непонятно, что требуется, IMHO.

самый простой и скучный ответ :)

ну а чо городить неоптимальное

ну а чо городить неоптимальное

1. мир не идеален :) 2. лишняя зависимость или оверхед в данном случае.

энивей у тебя задача блогов и тегов, ее уже решили в век веб2.0

делай как на хабре написали

делай как на хабре написали

не поделитесь урлом?

к сожалению в дороге

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

ато потом сиков много чтобы прочитать

надо делать двойное наследование, сперва хеш от метрики а потом дата

теги отдельно лежат и мапят к айди метрики

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

для этого надо положить последовательно данные

самая жопа - сжимать данные в постгре плохо

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

create type value_type as enum ('int', 'double', 'string'); create table keys ( id SERIAL PRIMARY KEY, host_id SMALLINT REFERENCES hosts, value_type value_type NOT NULL, key TEXT NOT NULL ); create unique index keys_host_id_key_idx on keys(host_id, key); create table storage ( id SERIAL PRIMARY KEY, key_id INTEGER REFERENCES keys, timestamp TIMESTAMP WITHOUT TIME ZONE, value_int INTEGER, value_double FLOAT8, value_string TEXT, ... TAGS? );

вон ребята в прометеусе говорят что на измерение надо 16 байт. они жмут в среднем до 1.8 что ли

ну да хотел по key_id

ну да хотел по key_id

insert и select через функцию в нужный 'partition' через иммутабельную функцию.

теги же обычно на весь поток а не на измерение вешается

зачем тебе тег туда

disk=sda, disk=sdb - вот например тэги из двух прилетевших метрик

которые приходят с одного host_id

и в зависимости от key хочется использовать разные агрегаты, как sum так и avg но с группировкой по disk

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

так привяжи теги как хосты

потом начнёшь думать про шаблоны и сделаешь заббикс

в key_id засунуть и значение тэга

потом начнёшь думать про шаблоны и сделаешь заббикс

шаблоны тоже есть но немного другие ;)

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

Ну так сделайте нормализованное хранение, и всё.

Ну так сделайте нормализованное хранение, и всё.

ну вообщем оставил tags как hstore.

ну вообщем оставил tags как hstore.

Дело Ваше, конечно...

Дело Ваше, конечно...

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

ну вообщем оставил tags как hstore.

А чего не jsonb?

https://youtu.be/SNzOZKvFZ68

А чего не jsonb?

Хмм... на первый взгляд JSON(b) именно для тегов —- это уж скорее плохое решение... В чём плюсы по сравнению с остальными?

Хмм... на первый взгляд JSON(b) именно для тегов —- это уж скорее плохое решение... В чём плюсы по сравнению с остальными?

Даёт больше возможностей. Да он имеет точно такой же функционал как и hstore, но зачем себя ограничивать?

Даёт больше возможностей. Да он имеет точно такой же функционал как и hstore, но зачем себя ограничивать?

Что такое "больше возможностей"? Или, в смысле, только по сравнению с hstore?

С hstore

Даёт больше возможностей. Да он имеет точно такой же функционал как и hstore, но зачем себя ограничивать?

hstore, мне не нужно больше чем key-value + gin. https://gist.github.com/vadv/d140d39ce93d0577bfdf3800ed21e767 плюс есть такие замеры :)

hstore проще внутри устроен.

hstore проще внутри устроен.

поэтому мне кажется что он будет быстрее в моем юзкейзе k=v что подтверждают простые тесты ^^^^

поэтому мне кажется что он будет быстрее в моем юзкейзе k=v что подтверждают простые тесты ^^^^

Просто любопытно, имеют ли эти тесты хоть какое-то отношение к реальности... Т.е. у Вас действительно лишь сотни записей с сотнями "цифровых" тегов на каждый id?

Просто любопытно, имеют ли эти тесты хоть какое-то отношение к реальности... Т.е. у Вас действительно лишь сотни записей с сотнями "цифровых" тегов на каждый id?

ну если уменьшать кол-во тэгов и увеличивать кол-во записей все не так плачевно становиться

jsonb - это минимум 9.4. так что пока хер с ним. он не нужен.

jsonb - это минимум 9.4. так что пока хер с ним. он не нужен.

А это у Вас точно тэги? Я к тому, что зачем там key/value (а не просто массив tags)?