у вас не синтаксическая ошибка, SELECT INTO вполне себе будет работать в PL/pgSQL, а вот возвращать table нет смысла т.к. там всего одна строка

возникает проблема с уникальностью записей в индексах и констрейнтах. констрейнты с немедленной проверкой(immediate). вот последний выловленный случай: insert into etl.positions_upload (id, dt) select p.id, now() from sales.positions p left join etl.positions_upload u on p.id = u.id where p.id >= 313207545 and u.id is null order by p.id limit 1000000 ERROR: duplicate key value violates unique constraint "uqc_positions_upload_id" DETAIL: Key (id)=(318557849) already exists. в таблице sales.positions уникальность по полю id есть. в таблице etl.positions_upload уникальность по полю обеспечивается uqc_positions_upload_id. уровень изоляции при вставке по-умолчанию read committed.

Могу ошибаться, но дело, думаю, вот в чем. Индексы и ограничения ничего не знают про версионность - mmvc существует только на уровне таблиц. Поэтому, когда у вас производятся параллельные вставки пересекающихся данных, и одна транзакция успешно закоммитилась, в индексе или ограничении успешно появляется запись, мешающая первой транзакции. Тут нужны блокировки на уровне строк, как мне кажется кажется. Типа skip locked

Доброго дня. Подскажите, пожалуйста, по производительности pgcompactor на больших объёмах данных. У меня есть таблицы, приближающиеся к терабайту, а фул вакуум таких таблиц на этом сервере выполнялся порядка 12 часов. Сколько суток примерно может занять сжатие pgcompactor'ом, если в интернете пишут, что 15Гб он за 6 часов сжимает?

И можно ли с этим что-то поделать? Распараллелить, например

Denis Smirnov, спасибо за ответ! вы имели ввиду mvcc?

возникает проблема с уникальностью записей в индексах и констрейнтах. констрейнты с немедленной проверкой(immediate). вот последний выловленный случай: insert into etl.positions_upload (id, dt) select p.id, now() from sales.positions p left join etl.positions_upload u on p.id = u.id where p.id >= 313207545 and u.id is null order by p.id limit 1000000 ERROR: duplicate key value violates unique constraint "uqc_positions_upload_id" DETAIL: Key (id)=(318557849) already exists. в таблице sales.positions уникальность по полю id есть. в таблице etl.positions_upload уникальность по полю обеспечивается uqc_positions_upload_id. уровень изоляции при вставке по-умолчанию read committed.

Попробуйте, погуглить ON CONFLICT UPDATE, DO NOTHING. Или select where pg_try_advisory_xact_lock()

Denis Smirnov, спасибо за ответ! вы имели ввиду mvcc?

Да, мой телефон выдаёт очень забавные автозамены.

по поводу того что индексы ничего не знают про версионность, на сколько мне помнится, то в индексы добавляются ссылки на новые кортежи, после чего для всех последующих транзакций эти ссылки являются актуальными. Подозреваю, что наиболее верный ответ найду в исходниках, но пока нет времени туда залезть, поэтому в первую очередь надежда на тех, кто это может быть уже искал там:-)

по поводу того что индексы ничего не знают про версионность, на сколько мне помнится, то в индексы добавляются ссылки на новые кортежи, после чего для всех последующих транзакций эти ссылки являются актуальными. Подозреваю, что наиболее верный ответ найду в исходниках, но пока нет времени туда залезть, поэтому в первую очередь надежда на тех, кто это может быть уже искал там:-)

А может вам просто в insert добавить on conflict do nothing?

как раз сейчас это дописываю))

но это выглядит как костыль))

подозреваю, что появилось именно из-за таких ошибок))

но это выглядит как костыль))

И крякает как костыль)) Да, раньше такие вещи решались через loop с обработкой исключений и отправкой на новый круг...

по поводу того что индексы ничего не знают про версионность, на сколько мне помнится, то в индексы добавляются ссылки на новые кортежи, после чего для всех последующих транзакций эти ссылки являются актуальными. Подозреваю, что наиболее верный ответ найду в исходниках, но пока нет времени туда залезть, поэтому в первую очередь надежда на тех, кто это может быть уже искал там:-)

Кстати, я вот прочитал и задумался. Сколь я помню, ссылки на кортежи сразу заносятся в индекс. После этого, когда мы ищем строку в индексе мы получаем список ссылок, прогоняем их через карту видимости таблицы. Те ссылки на кортежи, которые не заморожены (то есть видны не для всех) перепроверяются в таблице с учётом идентификатора транзакции. Но при такой схеме все данные всех транзакций должны по комитету попадать в индекс, иначе как они там окажутся?

Вопрос. Есть данные user_id | unique_code 12 | NULL 13 | 2572 14 | 1640 15 | NULL Можно как-то сделать уникальный индекс колонки unique_code игнорируя NULL?

по умолчанию NULL и так игнориуется

CREATE UNIQUE INDEX tablename_idx ON tablename (unique_code) WHERE NOT unique_code IS NULL;

Хм.. странно. Спасибо. Видимо ошибку допустил какую вчера, потому что сопротивлялся делать уникальным

CREATE UNIQUE INDEX tablename_idx ON tablename (unique_code) WHERE NOT unique_code IS NULL;

Спасибо. Приму на вооружение

У меня как раз есть составные уникальные индексы

кто что использует для автоматического failover-а репликации ? pgbouncer + repmgr хорош в практике? Или есть что-то получше ?

Patroni (https://github.com/zalando/patroni), Pgbouncer и Haproxy

Игорь спасибо я его и выбрал после консультации с Валентином Гогичаишвили

Как ФИАС импортировать в postgres?

Написать парсер который в нужном вам виде вставит в бд

Это как самый крайний вариант я тоже рассматриваю

Но всеже может есть что-то готовое?

Там парсер писать 30 минут

https://github.com/Scondo/fiosm

сорри, промахнулся :(

Прикольно

https://github.com/asyncee/fias2pgsql

Вообще я всем этим геммороем мучаюсь чтобы получить список улиц города

а зачем тебе список улиц города?

просто осм не подойдёт? :)

Вообще я всем этим геммороем мучаюсь чтобы получить список улиц города

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

как одно из применений: Поступающие данные валидировать хранимкой

ой, это что-то страшное

ой, это что-то страшное

поддерживаю

Приходят ~100 000 адресов по дисконткам, нужно провалидировать.

это так делают места, в которые нельзя свой адрес вбить, если его забыли в каком-то реестре? :)

нужно провалидировать - пробей геокодером и посмотри, чтобы у всех accuracy: rooftop было

это так делают места, в которые нельзя свой адрес вбить, если его забыли в каком-то реестре? :)

Это так делают, когда люид сказали мне сделать форму, в которую они будут XML Отправлять с информацией о дисконтках, а я это на карте вывести должен с тепловой картой

так тем более зачем список улиц

прямой геокодинг и в путь :)

прямой геокодинг и в путь :)

К кому? OSM?

100 000 запросов (+/-50000) будет жрать зараз?

Или пошлёт?

весь осмовский стек поднимается локально

Сейчас задам вопрос без сарказма. Только для того чтобы понять что правильно понял. Поднять OSM на тойже машине. Стучаться к геокоодеру Правильно?

https://wiki.openstreetmap.org/wiki/Nominatim/Installation

поднять геокодер на своей машине

залить в него osm

стучаться локально

Спасибо

в зависимости от качества нормализации исходнях данных может оказаться, что тебе не нужен весь полный nominatim, а хватит osm2pgsql и селектов по таблице домов с addr:street= addr:housenumber=

вырезки по СНГ живут тут: http://gis-lab.info/projects/osm_dump/

утра всем

Есть таблица со следующими полями fam | name | lastname | fioподскажите, как можно в поле fio автоматически записывать значения из полей fam name lastname.

Есть таблица со следующими полями fam | name | lastname | fioподскажите, как можно в поле fio автоматически записывать значения из полей fam name lastname.

А вам доброго дня с востока страны. Записывать триггером на строку, например?

ERROR: S client not available

А вам доброго дня с востока страны. Записывать триггером на строку, например?

ну у меня уже обед )) можно пример пожалуйста...

Через полчасика можно, как сам с обеда приду)

)

create table person(id serial, fam text, name text, lastname text, fio text); create or replace function person_fio_tr() returns trigger as $$ begin if (tg_op in ('INSERT','UPDATE')) then new.fio := coalesce(new.fam,'')||' '||coalesce(new.name,'')||' '||coalesce(new.lastname,''); return new; end if; exception when others then raise exception '%', sqlerrm; end; $$ language plpgsql; create trigger person_tr before insert or update on person for each row execute procedure person_fio_tr(); insert into person (fam, name, lastname) values ('курт','кобейн','донольдович'); select * from person;

create table person(id serial, fam text, name text, lastname text, fio text); create or replace function person_fio_tr() returns trigger as $$ begin if (tg_op in ('INSERT','UPDATE')) then new.fio := coalesce(new.fam,'')||' '||coalesce(new.name,'')||' '||coalesce(new.lastname,''); return new; end if; exception when others then raise exception '%', sqlerrm; end; $$ language plpgsql; create trigger person_tr before insert or update on person for each row execute procedure person_fio_tr(); insert into person (fam, name, lastname) values ('курт','кобейн','донольдович'); select * from person;

спасибо

http://rhaas.blogspot.ru/2017/04/who-contributes-to-postgresql.html?m=1

коллеги, подскажите, а что обычно делают в такой ситуации:

# select count(*) from pg_locks; count -------- 126066 (1 row)

оно внезапно прыгает с 30к до 100к за секунду

при этом мастер холодный, а на слейве LA >= 60

А чем занят слейв судя по логам?

там есть селекты, но их процентов 15-20 от общего числа

он больше для фейловера

Ладно, а на что происходит в pg_locks? Я имею ввиду не про количество, а какие таблицы и чем заблокированы? Там есть что-то необычное?

апдейтами заблокированы

причем там апдейты точечные

ну то есть UPDATE "social_accounts" SET "token" = ... WHERE "social_accounts"."id" = 32277

интересно, что на 200 апдейтов айдишников всего три штуки

По идее все транзакции, которые проигрываются на мастере, через Wal отправляются один в один на слейв, где проигрываются. По идее, все то же самое происходило на мастере, но при этом мастер не нагружен... хорошо, а в логах мастера похожие апдейты происходили в этот момент?

это на мастере и происходит

а слейв ждет, пока мастер транзакции закроет

потому и подогревается

ну, как я понимаю

А репликация синхронная, как я понимаю. Мне кажется надо или делать асинхронную , или разбираться, почему так странно пишется в мастер.

Я бы начал со второго пункта

Смотрел оставание реплики от мастера в это время ?

ну возможно зависит от того, как именно смотреть

вот так его какбэ нет:

# select now() - pg_last_xact_replay_timestamp(); -[ RECORD 1 ]------------- ?column? | 00:00:00.032114