поменяйте auto на manual или disable

и пробуйте

поменяйте auto на manual или disable

сейчас попробую

synchronuous_commit=off ещё немножко спасёт

уже включен

сейчас попробую

manual The postmaster process is not handled by the init script, but manually controlling the cluster with pg_ctlcluster(1) is permitted. disable Neither the init script nor pg_ctlcluster(1) are permitted to start/stop the cluster. Please be aware that this will not stop the cluster owner from calling lower level tools to control the postmaster process; this option is only meant to prevent accidents during maintenance, not more.

можно както кэшировать в память перед записью ?

решите, чего вам там нужно :)

поменяйте auto на manual или disable

в 8м дэбиане, тоже авто и он не стартует после дизэйбла

протабайте postgresql

может как-то по другому называется

Я в дебианах не очень, не уверен, как сервис там называется )

протабайте postgresql

там есть дэфолтный postgresql.service но он с 9,6 не связан

Значит увы. со start.conf какие результаты?

поставил disabled и сработало! спасибо! хотя в 8м аналогичная настройки и он не стартует!

Значит увы. со start.conf какие результаты?

спасибо!

спасибо!

Ясно :) Рекомендую разбаниться в гугле, так-то, это вторая ссылка по запросу "debian postgrsql 9.6 service disable" =) https://serverfault.com/questions/542385/how-to-disable-1-version-of-postgresql-server-without-uninstalling-it

Ясно :) Рекомендую разбаниться в гугле, так-то, это вторая ссылка по запросу "debian postgrsql 9.6 service disable" =) https://serverfault.com/questions/542385/how-to-disable-1-version-of-postgresql-server-without-uninstalling-it

так в 8м аналогично все было и не стартовал

так в 8м аналогично все было и не стартовал

Не повод не попробовать другие варианты ) Я не уверен, как в дебе, в редхате можно вручную выпилить старт любого сервиса на этапах загрузки системы. Но это решение на уровне ОС, что не очень. Если есть возможность, лучше решать такую задачу на уровне приложения )

уже включен

wal_writer_delay попробовать поднимать. ну и вообще, смотреть, что на вашей нагрузке на физическом уровне происходит

Не повод не попробовать другие варианты ) Я не уверен, как в дебе, в редхате можно вручную выпилить старт любого сервиса на этапах загрузки системы. Но это решение на уровне ОС, что не очень. Если есть возможность, лучше решать такую задачу на уровне приложения )

спасибо

ну, это как предположение, почему на 8 оно работает

не за что

можно както кэшировать в память перед записью ?

можно рисковать дальше и монтировать fs с nobarrier

wal_writer_delay попробовать поднимать. ну и вообще, смотреть, что на вашей нагрузке на физическом уровне происходит

спасибо, сейчас попробуем

там есть дэфолтный postgresql.service но он с 9,6 не связан

вроде как связан :)

в юните постгре9.6 написано что ето часть постгре.сервайс

так что поидее связан :)

так что поидее связан :)

в 8м дэбиане то же самое, но он не стартует)

может там системд старее и непонимает ту строку с юнита, хз))

192 коннекта в БД насколько много чтобы думать о пулинге коннектов?

192 коннекта в БД насколько много чтобы думать о пулинге коннектов?

пулинг экономит переоткрытия в основном

а на парсинг планов?

библиотечный кэш экономит наверно, допустим у пользователя 22 коннекта в БД, если будет 1 коннект через пулинг то библиотечный кэш каждого коннекта как бы в 22 раза больше. нет?

что такое библиотечный кэш?

планы запросов

вы точно чатиком не ошиблись? тут про постгрес :)

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

в постгресе его нет

https://habrahabr.ru/company/postgrespro/blog/275755/

хреново

нет, ну в постгресе кэш плана запросов есть. просто он требует prepared statements и уникален для каждого соединения

и даже пулинг может помочь. но опять же, для prepared statements

ну их надо спецально готовить, чтобы сохранять значит?

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

тут зависит от языка. говорят, что JDBC автоматически использует prepared statements

нет, ну в постгресе кэш плана запросов есть. просто он требует prepared statements и уникален для каждого соединения

планы могут построиться ещё и внутри хранимок на plpgsql

планы могут построиться ещё и внутри хранимок на plpgsql

ok, спасибо. но тут мне кажется о другом речь

нет, ну в постгресе кэш плана запросов есть. просто он требует prepared statements и уникален для каждого соединения

нету, это совсем разные вещи

нету, это совсем разные вещи

а я говорил, что это одинаковые вещи?

а я говорил, что это одинаковые вещи?

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

если что я тут мимо проходил, @stalkerg мне кажется тут самое место упомянуть srplan

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

нет, думаю при переходе с оракла в чем просядем

скиньте IT стикеры

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

я с практической точки зрения могу сказать, что использование prepared statements экономит почти 50% на времени выполнения для простейшей read-only нагрузки

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

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

я с практической точки зрения могу сказать, что использование prepared statements экономит почти 50% на времени выполнения для простейшей read-only нагрузки

о да! При условии что у вас много простых запроссов то это помогает, т.к. кешируется какраз всё что связанно с разбором. Но очень часто люди сталкиваются с тем что у них есть километровый запросс, который вот надо иногда запускать со стабильными показателями.

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

текущий оптимизатор, это больное место, уже давно думают поменять или как то подпилить

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

надо уходить от Вулкана к пушь модели

надо уходить от Вулкана к пушь модели

А что такое Вулкан?

А что такое Вулкан?

Volcano модель экзекьютора

Спасибо, почитаю.

ERROR: S client not available

Скажите пожалуйста, как получить время в секундах для локального времени? Делаю так: SELECT extract(epoch FROM localtime) С этим все ок, но надо явно таймзону указать: SELECT extract(epoch FROM localtime at time zone 'HKT') И тут почему-то выдает секунды по UTC

epoch не бывает в таймозоне

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

Нужно получить количество секунд с начала суток, как без epoch?

селектом от current_timestamp

Нужно получить количество секунд с начала суток, как без epoch?

select extract( epoch from (now() - now()::date::timestamptz));

https://dba.stackexchange.com/questions/81035/get-seconds-of-day-in-postgres

селектом от current_timestamp

Спасибо, что надо! SELECT extract(epoch FROM (current_timestamp at time zone 'HKT')::time)

как вариант select extract (epoch from (now() - date_trunc('day', now())));

Всем привет! В таблице есть колонка timestamp. Я делаю SELECT * из этой таблицы. Как сделать так, чтобы timestamp возвращался в определнном формате по этому запросу?

если тебе не подходит шорткат *, ты можешь расписать колонки списком

если тебе не подходит шорткат *, ты можешь расписать колонки списком

ну вот и не хочеться этого делать :)

если тебе не подходит шорткат *, ты можешь расписать колонки списком

Ну или как тогда привести это поле к нужному виду?

Ну или как тогда привести это поле к нужному виду?

https://www.postgresql.org/docs/9.6/static/datatype-datetime.html Там есть функции для работы с датами/таймстампами

Господа, есть вопрос. Насколько плохо на базе (как в смысле распухания, так и в смысле поедания буферов и проч.) скажется частое использование временных таблиц для массового обновления данных? Конкретно, надо раз в N минут массово обновлять некоторые записи. Думаю сделать COPY во временную (на время транзакции) таблицу и UPDATE t1 SET t1.foo = t2.foo WHERE t1.id = t2.id. Обновлены могут быть десятки тысяч записей.

Нашел статью http://www.dbrnd.com/2016/03/postgresql-the-awesome-table-fillfactor-to-speedup-update-and-select-statement/

кто-то может поделится опытом использования FILLFACTOR?

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

Fillfactor тащит

Прям сильно

На апдейтах

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

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

Почему?

Думаю он увеличит тяжесть фуллсканов - если они случатся

а есть сейчас что-то лучше pgAdmin4 ,

?

а есть сейчас что-то лучше pgAdmin4 ,

pgAdmin3

мне под веб надо

phppgadmin - внезапно, ага. Правда я им не пользовался, сразу говорю, мне пока что psql за глаза хватает.

phppgadmin - внезапно, ага. Правда я им не пользовался, сразу говорю, мне пока что psql за глаза хватает.

Он немного архаичен, но вроде пользовались на прошлой работе

Кстати, а вот вопрос, я тут мал-мала с пыхпыхом развлекаюсь - имеет смысл взять сей продукт и пошерстить его для привести в съедобное состояние? И если имеет - чему сей программ научить, от чего отучить, ну и вот это фсйо?