Спасибо)

не умеет грузить xml эта фича находится в todo

Понял. Обычно там где можно экспортировать в xml можно наверное и в csv

Понял. Обычно там где можно экспортировать в xml можно наверное и в csv

я не экспортирую, так код миграций БД в системе контроля версий хранится

Всем привет. А кто здесь админ?

Большая часть присутствующих тут - админы

Как провести такое преобразование? Чем сплитнуть столбцы по строкам?

coalesce очевидно

coalesce очевидно

Точно, спасибо

Большая часть присутствующих тут - админы

Тогда обращусь не напрямую, а ко всем. Можно здесь прорекламировать группу о MySQL? Ссылка на эту группу уже присутствует там.

Отчего бы и нет. Тут всем рады.

https://t.me/mysql_ru

Эту?

Эту?

Да. Её. Но изменил ссылку на t.me/mysql_db

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

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

а смысл несколько языков в одной группе ?

я про те языки на которых люди говорят

а смысл несколько языков в одной группе ?

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

Всем привет! Как в pg можно создать 2 одинаковых таблицы, только чтобы их ничего не связывало? CREATE TABLE IF NOT EXISTS test (like test_copy INCLUDING DEFAULTS). Пробовал так, но у них общий primary key

Что значит "общий primary key"? Не может быть у двух таблиц общий индекс. Или вы хотите вторую таблицу вообще без всех constraint сделать?

Видимо, сиквенс для сериала общий

Note that copying defaults that call database-modification functions, such as nextval, may create a functional linkage between the original and new tables.

Что значит "общий primary key"? Не может быть у двух таблиц общий индекс. Или вы хотите вторую таблицу вообще без всех constraint сделать?

если сделать select id=5 из одной таблицы в другую, то у строки будет id=6

Это потому, что include defaults указали. @crux правильно говорит. Видимо, нужно руками создать новый сиквенс, и переназначить дефолт.

Имхо, лучше скопировать дефинишн таблицы и просто создать новую, без всяких LIKE

С другой стороны, id обычно суррогатный ключ, и вам должно быть все равно, что в нём. Главное, чтобы за границу не выпал. Он ведь bigint?

у меня id, это номер поста, как на хабре. Или это не правильно?

И что? Какая разница, какой номер у поста?

Нужно только чтобы номера были уникальными.

во мне плачет маленький перфекционист, когда номер страницы будет 1, потом 250,23,5000 и т.д.

хотя наверное вы правы, это не особо важно

можно же перелинковать на другой сиквенс, раз вариант с "просто создать таблицу" не подходит

можно же перелинковать на другой сиквенс, раз вариант с "просто создать таблицу" не подходит

да, я создам таблицу наверное или еще подумаю, это это я уже на отвлеченные тамы перешел. Спасибо всем за помощь

коллеги, взгляните SELECT mb.promocode_id, SUM(x.amount) AS expenses FROM mailing_brand AS mb JOIN expense x ON (x.mailing_brand_id = mb.id) WHERE mb.brand_id = 4 AND mb.is_deleted = FALSE AND mb.promocode_id IS NOT NULL AND x.billed_at >= NOW() - interval '1 month' AND x.billed_at <= NOW() AND x.brand_id = 4 GROUP BY mb.promocode_id; на expense есть индексы на (billed_at), и на (brand_id, billed_at). Почему база не выбирает второй? https://explain.depesz.com/s/Ami0 не то чтобы это очень важно, просто интересно.

коллеги, взгляните SELECT mb.promocode_id, SUM(x.amount) AS expenses FROM mailing_brand AS mb JOIN expense x ON (x.mailing_brand_id = mb.id) WHERE mb.brand_id = 4 AND mb.is_deleted = FALSE AND mb.promocode_id IS NOT NULL AND x.billed_at >= NOW() - interval '1 month' AND x.billed_at <= NOW() AND x.brand_id = 4 GROUP BY mb.promocode_id; на expense есть индексы на (billed_at), и на (brand_id, billed_at). Почему база не выбирает второй? https://explain.depesz.com/s/Ami0 не то чтобы это очень важно, просто интересно.

А что это у вас такие большие ошибки в оценках на, вроде бы, простых предикатах (может, ANALYZE не было)? Что, если сделать VACUUM ANALYZE по таблицам?

интересно. после vacuum analyze expense план не поменялся, а после vacuum analyze mailing_brand изменился кардинально.

теперь используется (brand_id, billed_at)

это при том, что в mailing_brand жалкие 183 строчки

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

теперь используется (brand_id, billed_at)

я наврал. теперь используется (mailing_brand_id, billed_at)

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

Значит, по оценке этот дешевле. ;) На самом деле, чтобы узнать, нужно сравнить планы с ним и без него. Например: BEGIN TRANSACTION; DROP INDEX ... ; EXPLAIN (ANALYZE) ...; ROLLBACK;

угу, понятно

спасибо!

Значит, по оценке этот дешевле. ;) На самом деле, чтобы узнать, нужно сравнить планы с ним и без него. Например: BEGIN TRANSACTION; DROP INDEX ... ; EXPLAIN (ANALYZE) ...; ROLLBACK;

Лучше скрывать индексы от планировщика через pgtuner

Имелся ввиду plantuner ?

Есть у кого идеи как сбилдать PLV8 2.1 под винду?

Как изменить тип переменой в функции?

var::newtype если возможно

получили очень странное после апдейта 9.6->10.3

analyze кластеру сделали?

реиндекс всей БД не помог, в какую сторону вообще можно покопать?

reindex, не analyze

analyze сделать

reindex-то зачем?

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

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

amcheck что говорит?

не смотрели :(

не смотрели :(

https://gist.github.com/Komzpa/994d5aaf340067ccec0e

там есть такое: sudo su postgres -c "/usr/lib/postgresql/10/bin/vacuumdb --all --analyze-in-stages"

Это делали

а где легенда от графика? что жёлтое и что красное?

пардон, всё отрезал :(

желтое - iowait, красное - system time

желтое - iowait, красное - system time

Планы-то запросов те же? Или поплыло всё?

с учетом того что приложение и данные не менялись - планы тоже должны были остаться теми же

то есть единственное что было изменено - версия БД

с учетом того что приложение и данные не менялись - планы тоже должны были остаться теми же

А по факту? Может, там один запрос взбесился и всего делов

по графику похоже что выросла нагрузка на диск

А по факту? Может, там один запрос взбесился и всего делов

по срезу от Pgbadger - всё осталось на своих местах, просто пропорционально подросло

dstat, iotop точно показывает что PG грузит больше всех ?

dstat, iotop точно показывает что PG грузит больше всех ?

Logger, writer, wal

на одном из дисков заметно поднялся write, но так как он - часть lvm, нельзя сказать кто именно и чем именно его занял

а размер базы большой ?

~400gb база памяти 80гб, 16 ядер от 2x e5-2430 ssd диски (три штуки в lvm) ~90M Запросов в сутки

tmpfs юзаете?

http://linuxscripter.blogspot.com/2013/09/using-tmpfs-to-improve-postgresql.html

это вот единственная заметная аномалия

можно таки попросить скрин dstat ?