подходит. но я бы хотел знать чем отличается вот от этого (col - CAST(col as Integer)) <> 0

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

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

самый оптимальный какой )

что лучше?

оптимальный по какому критерию?

сколько раз будет работать этот запрос? :)

быстрота на первом месте.

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

Безусловно, только "(col - CAST(col as Integer)) <> 0" —- неправильный (как насчёт переполнения integer?).

быстрота на первом месте.

тогда тебе нужно написать сишный экстеншен и использовать векторные операции

Безусловно, только "(col - CAST(col as Integer)) <> 0" —- неправильный (как насчёт переполнения integer?).

число может быть максимум 10

там не большие числа

тогда where i in (0,1,2,3,4,5,6,7,8,9,10) ?

быстрота на первом месте.

Вы маетесь преждевременной оптимизацией, IMHO. ;)

Вы маетесь преждевременной оптимизацией, IMHO. ;)

мне кажется trunc подойдет. Спасибо большое.

Подскажите, кто сталкивался. Есть какие-нибудь наработки, процедуры, станарты в ключе Postgre под 1С?

У нас в ПгПро ребята много занимались поддержкой 1С для Посгреса. Читали например https://postgrespro.ru/products/1c_build ?

Спасибо, сейчас почитаю

привет кто может по опыту сказать какой уровень сжатия с пгдамп самый адекватный? в плане есть ли смысл на 9 сжимать, мб 6 оптимальный по времянасжатие/размердампа понятное дело что зависит еще от данных, но все же

привет кто может по опыту сказать какой уровень сжатия с пгдамп самый адекватный? в плане есть ли смысл на 9 сжимать, мб 6 оптимальный по времянасжатие/размердампа понятное дело что зависит еще от данных, но все же

А вам это вообще зачем? В смысле, сжатый дамп?

чтобы базу слить быстрее)

в смысле зачем сжимать? или зачем дамп

какая исходная решаемая задача

Обычно следует использовать минимальный уровень сжатия. Степень сжатия от увеличения уровня возрастает не сильно (<30%), а вот время - существенно - в разы. По крайней мере это справедливо для zlib и zstd. Причём некторые искуственные данные (pgbench -i) zstd умудряется жать ... хуже с максимальным рекомендуемым уровнем сжатия, чем на самом быстром.

в смысле зачем сжимать? или зачем дамп

Да, зачем дамп. От этого же всё зависит (кстати, причём тут опыт, я не очень понимаю —- вряд-ли DBA этим систематически занимаются)...

задача бэкап делать и восстанавливать в другой базе

Обычно следует использовать минимальный уровень сжатия. Степень сжатия от увеличения уровня возрастает не сильно (<30%), а вот время - существенно - в разы. По крайней мере это справедливо для zlib и zstd. Причём некторые искуственные данные (pgbench -i) zstd умудряется жать ... хуже с максимальным рекомендуемым уровнем сжатия, чем на самом быстром.

спасибо

задача бэкап делать и восстанавливать в другой базе

pg_dump —- не инструмент для backup-а. А если вам нужно перенести / скопировать дамп, то зависит от железа (сеть/CPU/диски), т.е. сходу не скажешь.

pg_dump —- не инструмент для backup-а. А если вам нужно перенести / скопировать дамп, то зависит от железа (сеть/CPU/диски), т.е. сходу не скажешь.

ват а что это тогда и какие варианты?

ват а что это тогда и какие варианты?

Это —- инструмент снятия дампов. А варианты —- pg_basebackup (или аналогичные сторонние решения), и затем решения, основанные на WAL (архвирование, репликация). В некоторых случаях могут и filesystem snapshots подойти (если fs это умеет).

Это —- инструмент снятия дампов. А варианты —- pg_basebackup (или аналогичные сторонние решения), и затем решения, основанные на WAL (архвирование, репликация). В некоторых случаях могут и filesystem snapshots подойти (если fs это умеет).

посмотрю, спасибо =)

подскажите про ОСМ люди добрые ) есть несложный запросик: https://gist.github.com/az09/925275a24eea4b095e630f7c0df7f01d однако выполняется он черезчур долго: https://explain.depesz.com/s/Grh что посоветуете, как на это повлиять можно?

9 секунд на 5 тыщ объектов, это 2 мс на объект

насколько понимаю из полученных по индекс-скану примерно 110К полигонов фильтруется довольно много записей Rows Removed by Filter: 106273 остаётся всего-лишь 4045

может добавить индекс по name?

во-первых грохнуть isvalid

во-вторых постараться грохнуть pointonsurface

в-третьих добавить индекс по geom where name is not null

во-первых грохнуть isvalid

-2,5 сек

в-третьих добавить индекс по geom where name is not null

ага, вот это видится мне самым верным путем ?

тогда в него же можно и ST_IsValid(way) засунуть

ok, надо поизучать значит как управлять созданием индексов в osm2pgsql

руками после него

я когда-то темплейты заводил https://github.com/Komzpa/furry-sansa/blob/master/assets/index.template.sql

руками после него

колхоз, не? )

в Беларуси всё нормально с сельским хозяйством, так что спасибо за комплимент

ничего личного (но комплимент с меня таки) ну просто это ж каждый раз не забыть еще дополнительный скрипт запустить... лучше было бы в lua там какой прописать и забыть

ну вот я для того выше апдейтер-враппер и писал

чтобы не звать руками и не забывать

Наткнулся на неплохую систему мониторинга "pgwatch2" от Cybertec (Collector(GO)+InfluxDB+Grafana). Кто ни будь уже успел познакомиться? https://github.com/cybertec-postgresql/pgwatch2

господа, ограничивал кто-то постгрес через cgroup и/или nice? что-то у меня эта штука(и) не реагирует на процесс

Через systemd очень удобно. Но делать этого не стоит

Через systemd очень удобно. Но делать этого не стоит

не стоит по какой причине?

Мнение не экспертное. Я считаю, из-за того, что, например, тот же backend пишет не только свои данные но и всего кластера. Следовательно, ограничив одну бд или юзера (даже не знаю как), ты зажмешь весь кластер. Либо ограничить кластер целиком (что и проще) и жить там только одной бд. И несколько кластеров на одной машине. Но Владимир Бородин говорил, что даже на таком очевидно ограничении как CPU приходят грабли.

цель вообще ограничить аппетиты update (причем процедура "технического" характера, которая применяется к некоторым статическим данным), а то во время его выполнения select'ы не проходят

Значит вы не про то думаете

наведете на верное русло?

Задача бд выполнить запрос наиболее эффективно и желательно быстро. Задача приложения - ограничивать аппетиты

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

Диски у вас какие ? иесть ли рэйд ?

Какая нагрузка на диски во время пакетного Апдейта *?

господа, ограничивал кто-то постгрес через cgroup и/или nice? что-то у меня эта штука(и) не реагирует на процесс

А как пришли к выводу, что нужно ограничивать?

господа, ограничивал кто-то постгрес через cgroup и/или nice? что-то у меня эта штука(и) не реагирует на процесс

pidstat -d 1 что показывает, процесс много кушает? pv -d <pid> ещё посмотрите

Диски у вас какие ? иесть ли рэйд ?

раньше были sas, сейчас 5+ рейд из 8ми sata

А как пришли к выводу, что нужно ограничивать?

пока cgroups заработал более менее нормально, но не сказать что хорошее решение + ночью (23:59-08:00) включаю на полную

Завтра в Екатеринбурге будет митап про базы данных. Если будете недалеко - приходите https://events.yandex.ru/events/meetings/25-april-2018

пока cgroups заработал более менее нормально, но не сказать что хорошее решение + ночью (23:59-08:00) включаю на полную

Ограничавать-то почему решили, одно ядро на сервере? ?

Доброго времени суток, версии внутри одной и той же мажорной и минорной версии сохраняют обратную совместимость? Например, запросы которые написаны для 9.6.8 будут работать в 9.6.1?

Подскажите, кто сталкивался. Есть какие-нибудь наработки, процедуры, станарты в ключе Postgre под 1С?

Завтра в Екатеринбурге будет митап про базы данных. Если будете недалеко - приходите https://events.yandex.ru/events/meetings/25-april-2018

Трансляция планируется, для тех кто не окажется недалеко?

Привет! I need help (С). Смигрировал БД для zabbix с mysql на pgsql 9.6, настроил партицирование. Проблема - при удалении таблиц-партиций место не освобождается! Читал доку, vacuum не должен помогать, на всякий случай сделал, без результата. Таблиц уже в объектах нет. Не пойму что теперь делать, место на диске утекает. Может кто даст добрый совет?

Трансляция планируется, для тех кто не окажется недалеко?

Привет! На сколько я знаю нет, ни записи ни трансляции.

Доброго времени суток, версии внутри одной и той же мажорной и минорной версии сохраняют обратную совместимость? Например, запросы которые написаны для 9.6.8 будут работать в 9.6.1?

Внутри одной major version (9.6.1--9.6.8 или 10.1--10.3) —- да, будут работать (не считая изменений вследствие исправления ошибок, естественно, но это бывает крайне редко).

Привет! I need help (С). Смигрировал БД для zabbix с mysql на pgsql 9.6, настроил партицирование. Проблема - при удалении таблиц-партиций место не освобождается! Читал доку, vacuum не должен помогать, на всякий случай сделал, без результата. Таблиц уже в объектах нет. Не пойму что теперь делать, место на диске утекает. Может кто даст добрый совет?

Как вы удаляете? И место где, как вы проверяете?

Внутри одной major version (9.6.1--9.6.8 или 10.1--10.3) —- да, будут работать (не считая изменений вследствие исправления ошибок, естественно, но это бывает крайне редко).

Спасибо, я правильно понял, что у постгреса первые две цифры это мажорная версия?

Спасибо, я правильно понял, что у постгреса первые две цифры это мажорная версия?

До 10-ки —- да. Начиная с неё —- major.minor.

Как вы удаляете? И место где, как вы проверяете?

drop table history_uint_pXXXX. Проверяю запросом по таблице select pg_relation_size('history_uint')/1024/1024 as size_mb;

drop table history_uint_pXXXX. Проверяю запросом по таблице select pg_relation_size('history_uint')/1024/1024 as size_mb;

Нашел проблему, данные попадают в основную таблицу, а не в подчиненную. Прошу прощения за беспокойство ?

drop table history_uint_pXXXX. Проверяю запросом по таблице select pg_relation_size('history_uint')/1024/1024 as size_mb;

И что этот запрос возвращает (если history_uint —- основная таблица, то это только её размер, без наследников)? А, вижу, разобрались. ;)

Привет! I need help (С). Смигрировал БД для zabbix с mysql на pgsql 9.6, настроил партицирование. Проблема - при удалении таблиц-партиций место не освобождается! Читал доку, vacuum не должен помогать, на всякий случай сделал, без результата. Таблиц уже в объектах нет. Не пойму что теперь делать, место на диске утекает. Может кто даст добрый совет?

удаляете правильно, но проверяйте лучше: df -h $PGDATA до и после удаления

Ограничавать-то почему решили, одно ядро на сервере? ?

так не cpu, а io?

так не cpu, а io?

ok, а как поняли, что IO нужно прижать?

ok, а как поняли, что IO нужно прижать?

эмпирически: процесс по update начал сжирать все ресурсы по диску, и не давал делать другие запросы

iostat -xm 1 в колонках await r_await w_await что показывает?

iostat -xm 1 в колонках await r_await w_await что показывает?

после ограничения смотреть есть смысл? если есть, то: 10,8 108,3

после ограничения смотреть есть смысл? если есть, то: 10,8 108,3

вы записей 40-50 соберите и сюда скрин пришлите

до ограничения и после ?

до ограничения и после ?

это тогда уже вечерком :)

вы записей 40-50 соберите и сюда скрин пришлите

резонно

резонно

вот такой командой iostat -xmt 1 180 > /tmp/iostat_`hostname`_`date +%F_%H_%M_%S`.log & а потом результат сюда присылайте

вот такой командой iostat -xmt 1 180 > /tmp/iostat_`hostname`_`date +%F_%H_%M_%S`.log & а потом результат сюда присылайте

ок

Подскажите, а свой синтетический сахар сложно разрабатывать на подобии between?

Подскажите, а свой синтетический сахар сложно разрабатывать на подобии between?

Например синтетический age от поля даты between 18лет and 20лет, приведёт к виду Поле даты between(расчетная дата минимум когда было бы 20 лет) and (расчетная дата максимум когда выходит 18 лет)

А то разработка не хочет ломать себе мозг с расчетами дат, все просят индексов им запилить под аге(дата рождения)

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