А вот вопрос еще - от BRIN вообще не будет толку, если данные в таблице изменяются, правильно? Один апсерт, и тупл из какого-то блока BRIN ляжет в конец таблицы...

мы вчера выяснили прекрасное, если в таблицу всё вставлять copy, и удалять только truncate, то в нее никогда не придёт автовакуум и не заапдейтит visibility map, и index only scan не будет работать как надо

Спасибо. Есть одна БД которая только так и наполняется (как Extract и transformation для BI системы). Обращу на нее внимание

А вот вопрос еще - от BRIN вообще не будет толку, если данные в таблице изменяются, правильно? Один апсерт, и тупл из какого-то блока BRIN ляжет в конец таблицы...

Можно постоянно его актуализировать

мы вчера выяснили прекрасное, если в таблицу всё вставлять copy, и удалять только truncate, то в нее никогда не придёт автовакуум и не заапдейтит visibility map, и index only scan не будет работать как надо

А если copy не было, но был несколько раз truncate, то нормально все будет?

А если copy не было, но был несколько раз truncate, то нормально все будет?

ключевое - отсутствие delete и update

А если copy не было, но был несколько раз truncate, то нормально все будет?

Ну так смотри - при наполнении не copy - все становится нормально же

короче, если нет dead tuples, то автовакуум не вакуумит

ключевое - отсутствие delete и update

То есть достаточно одного update или delete?

короче, если нет dead tuples, то автовакуум не вакуумит

А понял

Значит это мне не грозит.

мы аккуратно обошли все обычные страшности mvcc, и напоролись на неожиданные :)

Вот всегдв интересно было: есть таблица с туплами формата (id integer, other_id integer, active bool). Мы изменяем в одном из туплов интегер или буль - постгрес запишет новую версию тупла в конец последнего блока, или изменит существующий тупл in-place, тк ширина данных одинаковая?

Вот всегдв интересно было: есть таблица с туплами формата (id integer, other_id integer, active bool). Мы изменяем в одном из туплов интегер или буль - постгрес запишет новую версию тупла в конец последнего блока, или изменит существующий тупл in-place, тк ширина данных одинаковая?

https://momjian.us/main/writings/pgsql/mvcc.pdf

о спаибо

Если, допустим у меня есть доступ к таблицам базы на отдельном сервере. Можно ли как-то синхронизировать определененые таблицы между серверами?

Мои таблицы (которые есть на стороннем сервере) при этом могут быть slave. Потому что у меня они только для чтения, записывать туда ничего не собираюсь

Мои таблицы (которые есть на стороннем сервере) при этом могут быть slave. Потому что у меня они только для чтения, записывать туда ничего не собираюсь

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

Всем доброго времени суток! Ребят а pgModeler версии 0.8.2 нормально дружит с PG 9.6.2?

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

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

Ребята, привет! ) Кто нибудь имел опыт миграции данных с mongo на postgres на продакшне?

Ребята, привет! ) Кто нибудь имел опыт миграции данных с mongo на postgres на продакшне?

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

Всем привет)))

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

для распределенного кэша - норм :)

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

Perfect! )))

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

и данные?

и данные?

Сделали вид, что монга их утеряла )

"Какая монга? Не было никакой монги!"

Мои таблицы (которые есть на стороннем сервере) при этом могут быть slave. Потому что у меня они только для чтения, записывать туда ничего не собираюсь

Лондайст не рассматривали?

"Какая монга? Не было никакой монги!"

Монга была. Мы не отрицаем. Но она самоликвидировалась©

странно что мало кто юзает tokumx, это та же монга только транзакционная

хотя может она уже не развивается

В общем универсального бесплатного решения, похоже, нет, придется пилить скрипты )

В общем универсального бесплатного решения, похоже, нет, придется пилить скрипты )

можно каким нибудь питоновским orm, сделать экспорт с монги в json, потом подгружать данные в питон скрипте и сохранять уже в таблицу конструкцией вида SomeCollection(**record).save(). долго но верно :)

можно каким нибудь питоновским orm, сделать экспорт с монги в json, потом подгружать данные в питон скрипте и сохранять уже в таблицу конструкцией вида SomeCollection(**record).save(). долго но верно :)

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

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

а зачем сразу писать в два места ? не проще ли будет старые данные из монги подцепить через fdw и создать материализованное представление ?

В общем универсального бесплатного решения, похоже, нет, придется пилить скрипты )

https://www.torodb.com/ http://www.highload.ru/2015/abstracts/1917.html

https://www.torodb.com/ http://www.highload.ru/2015/abstracts/1917.html

ага, эти решения я рассматривал, спасибо )

Очень боюсь что таблица раздуется до таких размеров, когда на быстром NVMe диске не хватит места для VACUUM FULL, уже было такое. Как это предотвратить и какие настройки смотреть?

ну не хватит, и что?

зачем тебе реклеймить это место, почему не хватит обычного vacuum и дописывать в дырки?

зачем тебе реклеймить это место, почему не хватит обычного vacuum и дописывать в дырки?

Хмм и правда. Если random io бесплатное, то незачем. Но у меня таблица 500гб без индексов, примерно 30% из нее изменяется каждый день - проблем не должно возникнуть?

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

спасибо за развернутый ответ! ) Да, общая концепция понятна, подумываем написать приложение для переброса, которое также будет вести логи в промежуточную базу )

спасибо за развернутый ответ! ) Да, общая концепция понятна, подумываем написать приложение для переброса, которое также будет вести логи в промежуточную базу )

даунтайм допустим? сколько данных? насколько сложная схема?

даунтайм допустим? сколько данных? насколько сложная схема?

достаточна сложна, сущностей очень много, как и связей, а даунтайм недопустим ))

красафчик ,но мы тут все про вакуум

Странная (или нет) тема - CTE не оптимизируются чтоли?

CTE - барьер оптимизатора

ERROR: S client not available

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

Лондайст не рассматривали?

А чем лондайст отличается от обычного импорт экспорта?

Чето почитал. Тут по сути только демон добавляется

чат, подскажи когда всё это закончится?

postgres=# SELECT pid, age(query_start, clock_timestamp()), usename, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc; pid | age | usename | query -------+--------------------------+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------- 28526 | -1 days -03:19:11.247527 | postgres | COPY osm_roads (id, osm_id, type, name, "name:en", "name:ru", tunnel, bridge, oneway, layer, ref, z_order, access, service, class, geometry) FROM stdin; + | | | 28525 | -1 days -03:19:11.248051 | postgres | COPY osm_roads (id, osm_id, type, name, "name:en", "name:ru", "name:zh", tunnel, bridge, oneway, layer, ref, z_order, access, service, class, geometry) FROM stdin;+ | | | 28524 | -1 days -03:19:11.248208 | postgres | COPY osm_buildings (id, osm_id, name, "name:en", "name:ru", type, "building:levels", "building:levels_string", geometry) FROM stdin; + | | | 28523 | -1 days -03:19:11.248215 | postgres | COPY osm_buildings (id, osm_id, name, "name:en", "name:ru", "name:zh", type, "building:levels", "building:levels_string", geometry) FROM stdin; + | | | (4 rows)

в смысле есть ли способ оценить сколько уже данных легло в таблицу и сколько еще осталось?

postgres=# \d+ osm_roads Did not find any relation named "osm_roads".

watch df

osm2pgsql рисует прогрессбар

да вот не взглянул позвчера... а с чем сравнивать теперь?

osm2pgsql рисует прогрессбар

импосм тоже рисует. и он 5-6 дней над планетой трудится например. подумал что дамп будет быстрее )

дамп же принципиально совершенно однопоточный

нет $ pg_restore -d osm_int -a -Fd -j 4 osm_int_dat

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

хдд

postgres=# SELECT pid, age(query_start, clock_timestamp()), usename, query FROM pg_stat_activity WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' ORDER BY query_start desc; pid | age | usename | query -------+--------------------------+----------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------- 28526 | -1 days -03:19:11.247527 | postgres | COPY osm_roads (id, osm_id, type, name, "name:en", "name:ru", tunnel, bridge, oneway, layer, ref, z_order, access, service, class, geometry) FROM stdin; + | | | 28525 | -1 days -03:19:11.248051 | postgres | COPY osm_roads (id, osm_id, type, name, "name:en", "name:ru", "name:zh", tunnel, bridge, oneway, layer, ref, z_order, access, service, class, geometry) FROM stdin;+ | | | 28524 | -1 days -03:19:11.248208 | postgres | COPY osm_buildings (id, osm_id, name, "name:en", "name:ru", type, "building:levels", "building:levels_string", geometry) FROM stdin; + | | | 28523 | -1 days -03:19:11.248215 | postgres | COPY osm_buildings (id, osm_id, name, "name:en", "name:ru", "name:zh", type, "building:levels", "building:levels_string", geometry) FROM stdin; + | | | (4 rows)

вот кстати не понял почему тут две таблицы вместо четырёх :-|

zh то есть то нету. непонятно

а какой самый крутой бинарный key-value storage?

Clickhouse?

не

Джентльмены, а кто мигрировал с Оракла на Постгрес?

Джентльмены, а кто мигрировал с Оракла на Постгрес?

а в чём вопрос?

С чего начать данный вопрос

Слышал, что есть подобные решения от Диасофт