я таких не припомню. я даже ни одного живого юзера с innodb + raw devices не видел

Так Inno в основном на линуксах, а там этот флаг даааавно есть. Проблемы были в основном на SunOs.

Я вот у себя в городе не знаю тоже ни одного ороклоида с raw

Asm который?

У нас на exadata

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

лицензия на oracle db запрещает публиковать, да. но "поделиться опытом" можно. думаю, написать на форуме "мы вот тут у себя включили, ух ты, +20%!" никто не запрещает

лицензия на oracle db запрещает публиковать, да. но "поделиться опытом" можно. думаю, написать на форуме "мы вот тут у себя включили, ух ты, +20%!" никто не запрещает

а если не следовать, отберут чтоли? )

это будет нарушением лицензии. что они в этом случае делают — понятия не имею

а кто знает эту историю, почему они запрещают?

https://danluu.com/anon-benchmark/

Asm который?

Да, asm (я не настоящий сварщик в оракле). Можете поделиться опытом по производительности?

Не могу )) На exadata всегда был asm - производительность хорошая. Тащит говноскрипты за счет диска и ядер. Но так как не использовал файловую систему на этих же дисках - то сравнить не могу. В других местах (тест и dev) у меня oracle на xfs или ext4. XFS хоть я ее и не люблю - ведет себя лучше, но честно говоря на тестовых схд уж очень медленная - < 300 iops

Да, asm (я не настоящий сварщик в оракле). Можете поделиться опытом по производительности?

RAC + ASM растянутый на разные СХД очень даже спасал в свое время от падений. Что же касается I/O не скажу. Давно не видел, что бы БД в диски упиралась.

Привет. По какой причине не запускается контейнер Докера с pgsql образом, пишет что данные с разных версий, но это не так на хосте и в контейнере используется 9.6, pgsql_1 | FATAL: database files are incompatible with server pgsql_1 | DETAIL: The data directory was initialized by PostgreSQL version 9.5, which is not compatible with this version 9.6.8.

Привет. По какой причине не запускается контейнер Докера с pgsql образом, пишет что данные с разных версий, но это не так на хосте и в контейнере используется 9.6, pgsql_1 | FATAL: database files are incompatible with server pgsql_1 | DETAIL: The data directory was initialized by PostgreSQL version 9.5, which is not compatible with this version 9.6.8.

в логе сообщение про то что у вас данные старой версии

но на хосте я использую 9.6 без проблем

volumes: - /var/lib/postgresql/9.6/main:/var/lib/postgresql/data

и дальше используйте, но pgdata - от старой версии

с новой версией бинаря работать не будет

нужно обновить

вообще зачем вам PostgreSQL?

это как

вообще зачем вам PostgreSQL?

Я хочу проект протестировать в докере, хочу подцепить данные из хоста

для того чтобы база эффективно работала необходимо чтобы версия данных (PGDATA) была совместима с бинарем который это обслуживает.

Я хочу проект протестировать в докере, хочу подцепить данные из хоста

pg_upgrade

pg_upgrade

ок спс, буду разбираться

Есть ли термин у такого подхода к версионированию данных , когда у каждого старого кортежа есть ссылка на n+1 кортеж?

Список ?

Вроде такие вещи SCD называю, только я не нашёл подходящий тип

Блокчейн)))

Еее , спасибо )

Хранишь хэш предыдущей исторической записи, проверяешь

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

при инсёрте 1 раз обновить, а при рекурсии каждый раз бегать

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

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

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

При этом все равно же надо будет хранить ссылку на актуальную версию ?

Чтобы выгрузить все версии

Тогда сразу схему с версионированием делай

Актуальная версия - последняя

При этом все равно же надо будет хранить ссылку на актуальную версию ?

там еще какой-нть id-шник должен быть для группы кортежей (версий то бишь), по которому можно сгруппировать и найти последнюю дату

или как вариант хранить даты только для устаревших версий, а для актуальной - не хранить. Типа как xmax в постгресе

тогда выбирать актуальные версии проще

там еще какой-нть id-шник должен быть для группы кортежей (версий то бишь), по которому можно сгруппировать и найти последнюю дату

А, т.е. можно какой-нибудь uuid сгенерить ?

да нет, обычные 1, 2, 3

да нет, обычные 1, 2, 3

Да, разобрался, спасибо )

типа такого dt | id | данные ----------+----+----------- 1.03.2018 | 1 | версия 1 2.03.2018 | 1 | версия 2 null | 1 | весрия 3

Ребята привет Postgres 9.5 есть табличка 11 милионов записей за 4 года решили сделать partition, по дате создания по месяцу в итоге 48 подтабличек в них индекс по дате создания из главной таблички индекс дропнул(с ним еще медленнее чем было) смотришь explain PARTITION "Aggregate (cost=121844.24..121844.25 rows=1 width=8)" " -> Append (cost=0.00..114701.92 rows=2856929 width=0)" " -> Seq Scan on instance (cost=0.00..0.00 rows=1 width=0)" " Filter: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time < '2016-01-01 00:00:00'::timestamp without time zone))" " -> Seq Scan on instance_y2015m11 (cost=0.00..5905.96 rows=147464 width=0)" " Filter: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time < '2016-01-01 00:00:00'::timestamp without time zone))" " -> Seq Scan on instance_y2015m12 (cost=0.00..108795.96 rows=2709464 width=0)" " Filter: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time < '2016-01-01 00:00:00'::timestamp without time zone))" ONLY INDEX(BIG TABLE) "Aggregate (cost=164174.14..164174.15 rows=1 width=8)" " -> Index Only Scan using inst_created on instance (cost=0.44..157156.63 rows=2807004 width=0)" " Index Cond: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time <= '2016-01-01 12:00:00.156'::timestamp without time zone))"

кто сталкивался?

не те логи скинул

PARTITION "Append (cost=0.00..5914.41 rows=147466 width=442)" " -> Seq Scan on instance (cost=0.00..0.00 rows=1 width=441)" " Filter: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time <= '2015-12-01 00:00:00'::timestamp without time zone))" " -> Seq Scan on instance_y2015m11 (cost=0.00..5905.96 rows=147464 width=442)" " Filter: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time <= '2015-12-01 00:00:00'::timestamp without time zone))" " -> Index Scan using instance_y2015m12_created_time_idx on instance_y2015m12 (cost=0.43..8.45 rows=1 width=441)" " Index Cond: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time <= '2015-12-01 00:00:00'::timestamp without time zone))" ONLY INDEX(BIG TABLE) "Aggregate (cost=164174.14..164174.15 rows=1 width=8)" "Index Scan using inst_created on instance (cost=0.44..10638.46 rows=189948 width=442)" " Index Cond: ((created_time >= '2015-11-01 12:00:00.156'::timestamp without time zone) AND (created_time <= '2015-12-01 00:00:00'::timestamp without time zone))"

select * from instance where created_time >= '2015-11-01 12:00:00.156' AND created_time <= '2015-12-01 00:00:00.000' данные за один месяц

чек констрейнты прописаны?

констрейнт эксклюжон включен?

да

результат отсеивается

explain смотрел

Привет! Есть странная плавающая проблема на 9.6, SSD, iowait < 0.2: база как бы "подзалипает" на несколько секунд и начинает тупить.. примитивные запросы начинают попадать в slow.. подсткажите куда смотреть

локи, цпу, диск

Репликация есть? Synchronous_standby не задан ли?

Привет! Есть странная плавающая проблема на 9.6, SSD, iowait < 0.2: база как бы "подзалипает" на несколько секунд и начинает тупить.. примитивные запросы начинают попадать в slow.. подсткажите куда смотреть

Checkpoint. Можно статистику pgbadger собрать

Репликация есть? Synchronous_standby не задан ли?

да - есть, щас гляну...

Checkpoint. Можно статистику pgbadger собрать

Я чуть не понимаю о чем речь... Где что почитать?

Чекпоинты - механизм Postgres

Но на ssd странно было бы в них упереться, Да и iowait мелкий

У вас бд на физической машине машине или в виртуалке?

У вас бд на физической машине машине или в виртуалке?

железо

Привет! Есть странная плавающая проблема на 9.6, SSD, iowait < 0.2: база как бы "подзалипает" на несколько секунд и начинает тупить.. примитивные запросы начинают попадать в slow.. подсткажите куда смотреть

кстати archive_mode = on и там wal-e... это не может быть причиной?

Ну я бы для начала настроил мониторинг бд. Того же okmeter для траблшутинга хватит, можно mamonsu + zabbix, но там есть "тяжёлые" метрики которые сами по себе влияют на бд :-)

Репликация есть? Synchronous_standby не задан ли?

#synchronous_standby_names = '' # standby servers that provide sync rep

кстати archive_mode = on и там wal-e... это не может быть причиной?

Конечно может. Если его выполнение что-то задерживает

Ну я бы для начала настроил мониторинг бд. Того же okmeter для траблшутинга хватит, можно mamonsu + zabbix, но там есть "тяжёлые" метрики которые сами по себе влияют на бд :-)

вы не первый кто топит за okmeter, что там есть такого? у меня стоит libzbxpgsql

Он easy way для начинающих

Я юзаю mamonsu + пачку плагинов для всех нужд

Он easy way для начинающих

Как-то отрубать его не очень хочется на проде :)

Ну там нет опасных метрик, да и нового он вам ничего не даст.

Ну там нет опасных метрик, да и нового он вам ничего не даст.

вы про okmeter?

Конечно может. Если его выполнение что-то задерживает

допустим проблема в нем.. что использовать вместо? просто синкать их куда-то? потом уже бэкапить?

слейв справа

Я юзаю barman, там немного другой принцип работы

Wal receiver сам м забирает с сервера логи

Я юзаю barman, там немного другой принцип работы

а рекавери не проблема делать?

я делаю PITR для разработчиков обычно, но это не связано с вашей проблемой

попробуйте отключить архивацию

о это от 2nd quadrant

попробуйте отключить архивацию

щас буду пробовать

hot_standby_feedback = on - вот еще нашел

Checkpoint_timeout и checkpoint_completion_target чему равен?

Checkpoint_timeout и checkpoint_completion_target чему равен?

# grep checkpoint /var/lib/pgsql/9.6/data/postgresql.conf #checkpoint_timeout = 5min # range 30s-1h checkpoint_completion_target = 0.7 # checkpoint target duration, 0.0 - 1.0 #checkpoint_warning = 30s # 0 disables log_checkpoints = on

В файле postgresql.auto.conf есть чо?

В файле postgresql.auto.conf есть чо?

не - нет

Добрый вечер. Я решил сделать простую очередь задач в postgres и извлекаю новые задачи так: UPDATE parse_queue SET done = true WHERE id = ( SELECT id FROM parse_queue WHERE defered<now() and tryed < 3 and done != true ORDER BY priority DESC, RANDOM() FOR UPDATE SKIP LOCKED LIMIT 1 ) RETURNING id, job_type, priority И дальше в этой же транзакции делаю задачу и потом закрываю ее. В интернетах пишут что так лок должен быть только на строчку и нормально должны работать паралельные консьюмеры. Но сейчас задачи запрашивает много потоков, а отдаются они все равно синхронно, и пока одна не отработает, другому потоку задача не достанется. В чем может быть проблема?

а почему ты вообще и извлекаешь и апдейтишь что готово одним запросом

ты ж еще не обработал

или это у тебя промисы такие хитрые