Коллеги, а кто как разворачивает слейв для потоковой репликации, через basebackup или rsync?

Коллеги, а кто как разворачивает слейв для потоковой репликации, через basebackup или rsync?

basebackup + rsync потом, чтоб архивные wal-логи тоже приехали на слейв. А то мастер убегает.

basebackup + rsync потом, чтоб архивные wal-логи тоже приехали на слейв. А то мастер убегает.

https://postgrespro.ru/docs/postgrespro/9.5/app-pgbasebackup Ключевые слова: --xlog-method=stream --slot=имя_слота --write-recovery-conf

https://postgrespro.ru/docs/postgrespro/9.5/app-pgbasebackup Ключевые слова: --xlog-method=stream --slot=имя_слота --write-recovery-conf

Ух ты, а я мучался. Спасибо.

Коллеги, приветствую. есть запрос: select * from flowlog where ( ((timestart between 1498856400 and 1502139600) and timeend >= 0) OR (timestart <= 1498856400 and timeend = 0) ) and outsideip = '<secret_ip>'::inet order by timestart,insideip,outsideip B есть индекс: CREATE INDEX timeindex ON public.flowlog USING btree (timeend, timestart) TABLESPACE cgnatdb; Индекс почему-то не используется, и в explain всегда seq scan. PG 9.6

Сейчас объем таблицы не большой, но запрос отрабатывает 2.3-2.5 секу

Таблица порядка гигабайта

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

Коллеги, приветствую. есть запрос: select * from flowlog where ( ((timestart between 1498856400 and 1502139600) and timeend >= 0) OR (timestart <= 1498856400 and timeend = 0) ) and outsideip = '<secret_ip>'::inet order by timestart,insideip,outsideip B есть индекс: CREATE INDEX timeindex ON public.flowlog USING btree (timeend, timestart) TABLESPACE cgnatdb; Индекс почему-то не используется, и в explain всегда seq scan. PG 9.6

or в индексы не уйдёт

значит можно разбить на два запроса и через union склеить

или слишком костыльно?

так должно заработать, да

один скан - один интервал

Если бы использовали null вместо 0, запрос можно было бы переписать без or: between coalesce() and coalesce(), и создать функциональный индекс.

так себе затея

скорее похоже на tstzrange https://www.postgresql.org/docs/9.6/static/rangetypes.html и gist по нему

тогда можно для конца полноценно проставить бесконечность и проверять одно вхождение

gis=# select '[2010-01-01 14:30, infinity)'::tstzrange; tstzrange ------------------------------------- ["2010-01-01 14:30:00+02",infinity) (1 row)

Всем привет! В функции PQexecParams функция забирает владение параметрами, или их нужно самому очищать?

пхп что-ли?

тогда можно для конца полноценно проставить бесконечность и проверять одно вхождение

Ну, кстати, бесконечность да, хороший вариант! ?

пхп что-ли?

Где?

Коллеги, приветствую. есть запрос: select * from flowlog where ( ((timestart between 1498856400 and 1502139600) and timeend >= 0) OR (timestart <= 1498856400 and timeend = 0) ) and outsideip = '<secret_ip>'::inet order by timestart,insideip,outsideip B есть индекс: CREATE INDEX timeindex ON public.flowlog USING btree (timeend, timestart) TABLESPACE cgnatdb; Индекс почему-то не используется, и в explain всегда seq scan. PG 9.6

А какова семантика запроса? И почему индекс по (timeend, timestart) (а не по (timestart, timeend), например)? Впрочем, в виду того, что в постгрессе пока нет статистики по двум полям одновременно, для оптимизатора этот запрос выглядит как: вариант a) select * where timeend >= 0 вариант b) select * where timestart <= 1502139600 оба варианта ведут к логичному выводу: "всё равно нужно все записи просматривать, так зачем нам индекс?"

Где?

а, сорян. это сишная либа

Кто нибудь в курсе, как вставить в качестве параметра время для PQExecParams?

Может метод кто подскажет, как перевести time_t в строковое представление timestamp на C

Может метод кто подскажет, как перевести time_t в строковое представление timestamp на C

https://stackoverflow.com/questions/3053999/c-convert-time-t-to-string-with-format-yyyy-mm-dd-hhmmss

да, только что нашел

:)

Жаль что нельзя как бинарную дату засунуть, только к строке получается

Ух ты, а я мучался. Спасибо.

Да, и еще не забывайте про ключ: --checkpoint=fast

Кто нибудь в курсе, как вставить в качестве параметра время для PQExecParams?

а из клиентского приложения можно позвать time_t_to_timestamptz()? И потом TimestampTzGetDatum

а из клиентского приложения можно позвать time_t_to_timestamptz()? И потом TimestampTzGetDatum

Хм, не знаю, попробую, спасибо!

Приветствую.. Ктонибудь подскажет, почему экскепшин. кинутый из constraint trigger проглатывается системой и его нигде не видно? Код: CREATE OR REPLACE FUNCTION public.trf_check_staff_dublicates ( ) RETURNS trigger AS $body$ BEGIN raise exception 'test'; END; $body$ LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100; CREATE CONSTRAINT TRIGGER nr_pmu_mo_staff_detail_tr_unq AFTER INSERT OR UPDATE ON public.nr_pmu_mo_staff_detail DEFERRABLE INITIALLY DEFERRED FOR EACH ROW EXECUTE PROCEDURE public.trf_check_staff_dublicates();

Вопрос снят.. Баг EMS Postgresql Manager-a. c psql все норм: begin; BEGIN nr=# insert into nr_pmu_mo_staff_detail(staff_id,nr_pmu_depart_id, nr_pmu_depart_hospital_subdivision_id,post_id,total_rate) nr-# values(2,136161,1,150,1); INSERT 0 1 nr=# commit; ОШИБКА: test КОНТЕКСТ: функция PL/pgSQL trf_check_staff_dublicates(), строка 10, оператор RAISE

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

вроде как она откатится...

Заново

Понял, спасибо!

А если я два раза вызываю BEGIN, что происходит с операциями до второго BEGIN, она сбрасываются?

Так нельзя сделать. Он скажет transaction already in progress.

А, понял

спасибо

А у нас prepare сохраняются между коннектами?

Есть какой нибудь prepare if not exists?

Агрессивный автовакуум + pg_repack

pg_repack – это extension, а значит его много куда просто невозможно поставить или очень трудозатратно. Есть ещё compact_table, pgcompacttable и pgcompact — торжество опенсорса, каждый решил пилить свою ветку вместо объединения усилий ? В итоге у каждого свои минусы, да и все трое подзаброшены, судя по коммитам и PR. Хотя это направление намного интереснее pg_repack, т.к. не надо ничего ставить кроме стандартного pgstattuple (а он есть даже у RDS). то есть, в целом с этим ситуация плачевна или я что-то упустил?

А у нас prepare сохраняются между коннектами?

https://www.postgresql.org/docs/9.6/static/sql-prepare.html — тут сразу видно, что 1) "PREPARE name [ ( data_type [, ...] ) ] AS statement" нет if not exists; 2) "Prepared statements only last for the duration of the current database session."

pg_repack – это extension, а значит его много куда просто невозможно поставить или очень трудозатратно. Есть ещё compact_table, pgcompacttable и pgcompact — торжество опенсорса, каждый решил пилить свою ветку вместо объединения усилий ? В итоге у каждого свои минусы, да и все трое подзаброшены, судя по коммитам и PR. Хотя это направление намного интереснее pg_repack, т.к. не надо ничего ставить кроме стандартного pgstattuple (а он есть даже у RDS). то есть, в целом с этим ситуация плачевна или я что-то упустил?

всё плохо. "партиционируйте, транкейтьте, cluster"

?

всё плохо. "партиционируйте, транкейтьте, cluster"

drop забыл ))

ну если серьёзно к составлению такого списка подходить, на первом месте будет идти create index concurrently

create index concurrently не сделает репак таблицы

индекс - да

так самая большая беда не в распухании таблицы, а распухании индексов ?

и те же инструменты-заменители vacuum full дают ещё больше распухание. ну и сами же делают пересоздание индексов в итоге, т.к. там никаких больше рецептов пока нет

так самая большая беда не в распухании таблицы, а распухании индексов ?

а таблица только на добавление данных?

какая таблица? ?

таблиц много, проектов много, ситуации разные, беда у всех примерно одна, многие просто не замечают даже. Вот окметер или другие мониторилки добавят графики по вакууму — и замечающих сразу больше станет.

pg_repack – это extension, а значит его много куда просто невозможно поставить или очень трудозатратно. Есть ещё compact_table, pgcompacttable и pgcompact — торжество опенсорса, каждый решил пилить свою ветку вместо объединения усилий ? В итоге у каждого свои минусы, да и все трое подзаброшены, судя по коммитам и PR. Хотя это направление намного интереснее pg_repack, т.к. не надо ничего ставить кроме стандартного pgstattuple (а он есть даже у RDS). то есть, в целом с этим ситуация плачевна или я что-то упустил?

которая пухнет

а таблица только на добавление данных?

переиспользование дыр в heap нормально хендлит fsm

ERROR: S client not available

Айтуар, а все пухнут ? Из недавнего - у одного быстро растущего стартапа всякие разные ETL могут пачку DELETE отгрузить так, что никакая агрессия автовакуума уже не поможет.

Да, видимо всё таки придётся пробовать чисто NoSQL БД для таких таблиц.

?) это уже из разряда "придётся сменить род деятельности". Пора стартапу пивот делать

го все проверять свои индексы https://gist.githubusercontent.com/NikolayS/b6ec676ea63ab8d4db680a4c0d88e8bf/raw/5acc54c74d75549eedc4c5fada6099a2dff25bb5/02a_btree_bloat_simple.sql у кого как раздуло?

кажется, запрос не совместим с компрессией от pgpro

го все проверять свои индексы https://gist.githubusercontent.com/NikolayS/b6ec676ea63ab8d4db680a4c0d88e8bf/raw/5acc54c74d75549eedc4c5fada6099a2dff25bb5/02a_btree_bloat_simple.sql у кого как раздуло?

| table_size | index_size | index_scans | waste_percent | waste +------------+------------+-------------+---------------+------------- | 13 GB | 12 GB | 0 | 39.0 | 4930 MB | 13 GB | 12 GB | 0 | 39.0 | 4930 MB вот пару самых толстых

ну ведь не очень приятно же, да? но тут надо ещё учитывать, что у btree-индексов филлфактор по умолчанию 90. То есть там 10% места "резервируется"

ну ведь не очень приятно же, да? но тут надо ещё учитывать, что у btree-индексов филлфактор по умолчанию 90. То есть там 10% места "резервируется"

Микрооптимизация - выставлять филфактор в 100 для индекса первичного ключа по id (если id задается монотонно возрастающим сиквенсом)

Кстати, да, логично и просто. Спасибо.

Хотя. При апдейтах куда туплы-то пихать? Будет сплит, а значит -- деградация скорости апдейтов. При 90 в одной странице можно несколько ссылок держать, на разные туплы для одного и того же id, тут не важно, моното он заполнялся или нет. Важно — будут ли у нас апдейты. 100 имеет смысл ставить, если апдейтов точно не будет.

Хотя. При апдейтах куда туплы-то пихать? Будет сплит, а значит -- деградация скорости апдейтов. При 90 в одной странице можно несколько ссылок держать, на разные туплы для одного и того же id, тут не важно, моното он заполнялся или нет. Важно — будут ли у нас апдейты. 100 имеет смысл ставить, если апдейтов точно не будет.

Да, чет я не подумал о версионности... (все ещё в механизмах oracle думаю)

Всем привет. Подскажите, кто работал с jsonb. Пытаюсь сохранить данные в БД (Doctrine), как массив. Вот так он отображается в терминале: Array ( [0] => ["hunting"] ) В БД значение отображается так: ["[\"hunting\"]"] Что нужно сделать, чтобы значение приходило в БД в таком виде: ["hunting"] ? Понимаю, что нужно произвести действия над массивом, не могу понять, какие именно. В json_encode пробовал, становилось только хуже.

а как выглядит тот insert, что генерирует твой фреймворк?

У меня Silex, стандартные методы доктрины.

Здравствуйте! Не подскажите как определить на какое событие сработал триггер?

У меня Silex, стандартные методы доктрины.

думаю, это вопрос больше по php, чем про базу :)

Угу, уже в php чат тоже отписал )

извиняюсь за офтоп

https://ru.stackoverflow.com/questions/700323/Шахматка-из-sql-запроса-в-firebirddb

помогите плиз

если конечно это вообще реально

помогите плиз

воспользуйся postgres и \crosstabview

там firebird

данные можешь подтянуть https://github.com/ibarwick/firebird_fdw

Здравствуйте! Не подскажите как определить на какое событие сработал триггер?

https://www.postgresql.org/docs/9.0/static/plpgsql-trigger.html Вопрос не актуален

Интел представили новые серверные SSD, в форм-факторе "линейки". С ними можно будет воткнуть в одноюнитовый сервер до петабайта стораджа. Ну и важно, что не забыли поддержать хот-своп. В общем пока все идет к тому, что скоро мы все окончательно уедем на SSD, они дешевеют и растут в размерах, и это здорово. Человечество начало копить и обрабатывать данные, а это требует быстрого стораджа за разумные деньги. http://www.anandtech.com/show/11702/intel-introduces-new-ruler-ssd-for-servers

Реклама чЁли ?

Новый форм фактор

я уж прямо потянулся к плюсомёту