Експейн пишет просто append, и вторая часть union пишет never executed. Где почитать что именно parallel должно быть?

https://www.postgresql.org/message-id/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com

Рома какая разница будет если вернет не первую сначала а вторую. логика вроде бы допускает

Логика последовательна: если найдено по первой логике - искать по первой, если нет - по второй, и всего 5 разных запросов

Логика последовательна: если найдено по первой логике - искать по первой, если нет - по второй, и всего 5 разных запросов

не знаю, я бы наверно экзитс-ом 5 раз проверил (без юнионов всяких). пусть по-индусски, зато последовательность под контролем

не знаю, я бы наверно экзитс-ом 5 раз проверил (без юнионов всяких). пусть по-индусски, зато последовательность под контролем

Это как?

количество все равно нужно

и 1 branch, 2 branch тоже нужно, чтобы понять, по какому запросу нашлись записи

подскажите пожалуста где постгрес поучить

?

подскажите пожалуста где постгрес поучить

postgres-pro ??

https://postgrespro.ru/docs

спасибо

у прошек ещё и видео курсы есть, не самые современные, но вполне актуальные

и 1 branch, 2 branch тоже нужно, чтобы понять, по какому запросу нашлись записи

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

но я не настоящий сварщик, пусть меня поправят

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

Просто запрос, не батч

Попытка логики на чистом sql

чистый sql это миф ))

Всем счастья: https://www.theregister.co.uk/AMP/2018/01/02/intel_cpu_design_flaw

Самое главное select 1 что в тесте принимает участие. Дальше будем nop’ами тестить перформанс %))?

Amd просто в дамки

Они в дамки уже лет 40 как пытаются выбраться

Самое главное select 1 что в тесте принимает участие. Дальше будем nop’ами тестить перформанс %))?

Там read-only тоже есть. Просадка 16% и 7% с PCID. Согласись, это не мало.

Они в дамки уже лет 40 как пытаются выбраться

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

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

Допомогались )

Разработчики PostgreSQL отметили падение производительности в тесте pgbench на 23% (при использовании процессоров с PCID - 17%). https://www.opennet.ru/opennews/art.shtml?num=47849

Я вижу выход запускать ядро с опцией nopti на машине с базой, 23% - слишком серьезно

Да.. И бд обычно упрятана так, что не доберешься

Интересно, а как на хостовых машинах с виртуализацией будет? Т.е. если там вообще обновляют ядро будут ли включать nopti, или забьют на это.

Я вижу выход запускать ядро с опцией nopti на машине с базой, 23% - слишком серьезно

это пока нету IO 23%, когда начинает диск мучить там до 50%

автоваакум пойдёт и всё...

@tutchestniy какие виды репликации есть в постгресе? Что такое WAL? Что такое колоночноориентированная база данных?

жесть какая https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de Best case: 17% slowdown Worst case: 23%

@tutchestniy какие виды репликации есть в постгресе? Что такое WAL? Что такое колоночноориентированная база данных?

wal это Журнал Упреждающей Записи: сперва записал, потом сделал изменения. Изначально репликация была "физическая": писалось в каком файле на каком смещении какие байты поменять; потом добавили логическую, которую назвали logical decoding, в ней мастер сервер читает свой же wal и пытается разобрать какие не файлы а таблицы и строки стали какими. Колоночная база это такая, в которой данные хранятся не туплом (каждая колонка таблицы след за другом в пределах строки), а собственно колонками — сперва рядом хранятся значения первой колонки, затем второй, затем третей. Про колонки можешь почитать подробнее тут db.csail.mit.edu/projects/cstore/vldb.pdf

tuple ... ох ... кортеж это называется ...

tuple ... ох ... кортеж это называется ...

честно, кортеж у меня ассоциируется вообще с другим. Кто вообще решил использовать этот перевод? А то будет как с нитями которые теперь по ошибке стали потоками.

стоп, а как понять вот это? [1 2] [3 4] - массив ( не трогая нынешние понятия) ?

это же не словарь, в терминологии питона (хотя можно притянуть)?

и чем, кстати, у вас кортеж ассоциируется, с рапирой?

и чем, кстати, у вас кортеж ассоциируется, с рапирой?

с повозкой :) или с путиным, медведевым из-за которых стоишь в пробке. А так из вики: Торжественное шествие, процессия.

стоп, а как понять вот это? [1 2] [3 4] - массив ( не трогая нынешние понятия) ?

вы про массивы?

нет, именно кортеж (в интерпретации)

как раз tuple

Так кому хочется подробностей, что же такого ужасного у Интел, АМД и АРМ смотреть сюда https://googleprojectzero.blogspot.jp/2018/01/reading-privileged-memory-with-side.html

Ryzen пока кажись без этого бага, но надо ещё доказать

Больше всего проблем будет у тех, у кого паблик виртуалки на одном хосте

Тут Алекс уже достаточно много агрегировал, может кому-нибудь пригодится

вот как это работает — перехват пароля, используя Meltdown https://twitter.com/misc0110/status/948706387491786752/photo/1

хороший коммент: So for AMD, this appears to only impact Linux and FreeBSD users using an "APU" who've manually turned on the BPF JIT. Considering I had no clue this thing existed until now, I'm going to guess this impacts all of 3 users.

According to researchers, "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)."[6]

wal это Журнал Упреждающей Записи: сперва записал, потом сделал изменения. Изначально репликация была "физическая": писалось в каком файле на каком смещении какие байты поменять; потом добавили логическую, которую назвали logical decoding, в ней мастер сервер читает свой же wal и пытается разобрать какие не файлы а таблицы и строки стали какими. Колоночная база это такая, в которой данные хранятся не туплом (каждая колонка таблицы след за другом в пределах строки), а собственно колонками — сперва рядом хранятся значения первой колонки, затем второй, затем третей. Про колонки можешь почитать подробнее тут db.csail.mit.edu/projects/cstore/vldb.pdf

Спасибо но я знаю это ?

Привет всем! Я пытаюсь привязать бд cltest к rgenius_test с помощью postgres_fdw. https://gist.github.com/EdwinnaElbert/5b49185066152821e6747ab8521f777b. До этого то же самое успешно сработало с u developer и бд staging и clients, а тут почему-то не получается. Помогите, пожалуйста

В cltest и rgenius_test только схема

Всем привет. Посоветуйте пожалуйста какой-нибудь очень хороший онлайн курс по работе с postgres

@Kuzhagaliyev вчера пропустил

https://postgrespro.ru/docs

у прошек ещё и видео курсы есть, не самые современные, но вполне актуальные

Всем привет. Посоветуйте пожалуйста какой-нибудь очень хороший онлайн курс по работе с postgres

https://postgrespro.ru/education/courses Там в курсе и видео и все материалы

хай. вопрос по jsonb: update result set result = jsonb_set(result, ?, ?::jsonb, true) where id = ? returning result судя по логам, апдейты у меня идут верно, но некоторые ветки жсона как будто не меняются, подозреваю, что проблема в конкурентных апдейтах. вопрос: может ли так быть, что апдейт жсон-поля не атомарен?

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

хай. вопрос по jsonb: update result set result = jsonb_set(result, ?, ?::jsonb, true) where id = ? returning result судя по логам, апдейты у меня идут верно, но некоторые ветки жсона как будто не меняются, подозреваю, что проблема в конкурентных апдейтах. вопрос: может ли так быть, что апдейт жсон-поля не атомарен?

Если Вы не наткнулись на какой-то bug, то такого (не атомарного UPDATE) быть не должно. Можете подробнее описать ситуацию?

постгрес 10.1, апдейты из разных процессов в одной и той же строке по разным веткам

честно говоря, что ещё описать?

честно говоря, что ещё описать?

У есть Вас пример(ы) не меняющихся веток JSON и относящиеся к ним полные логи?

тестового конкретного случая, чтобы это можно было обозримо описать — нет. могу попробовать описать словами: таблица result, поле result структура: {"dns":{"example.com":{"NS":{"status":"PENDING"},"A":{"status":"PENDING"},... другие записи ...}}} по веткам внутри {dns,'example.com',$type} проходят апдейты из параллельных процессов (воркеры геармана)

тестового конкретного случая, чтобы это можно было обозримо описать — нет. могу попробовать описать словами: таблица result, поле result структура: {"dns":{"example.com":{"NS":{"status":"PENDING"},"A":{"status":"PENDING"},... другие записи ...}}} по веткам внутри {dns,'example.com',$type} проходят апдейты из параллельных процессов (воркеры геармана)

Если у Вас это стабильно воспроизводится, можете повторить с log_statement = all (или подобным), а потом найти record с проблемой и относящиеся к ней запросы? Но, скорее всего, у Вас где-то ошибка...

тестового конкретного случая, чтобы это можно было обозримо описать — нет. могу попробовать описать словами: таблица result, поле result структура: {"dns":{"example.com":{"NS":{"status":"PENDING"},"A":{"status":"PENDING"},... другие записи ...}}} по веткам внутри {dns,'example.com',$type} проходят апдейты из параллельных процессов (воркеры геармана)

Мне кажется, у вас в запросе jsonb_set( result ) - там уже другой result (из-за параллельных апдейтов). Возможно не перетирание json, а конкатенация спасет. update result set result |= jsonb_set(result, ?, ?::jsonb, true) where id = ? returning result

чегой та он другой?

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

Если у Вас это стабильно воспроизводится, можете повторить с log_statement = all (или подобным), а потом найти record с проблемой и относящиеся к ней запросы? Но, скорее всего, у Вас где-то ошибка...

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

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

Ну так попробуйте воспроизвести с logging, будет куда понятнее, что происходит. id —- это PK / unique index, кстати? Записи в процессе работы удаляются, добавляются (или только UPDATE)?

только апдейт. да, id serial primary key,

только апдейт. да, id serial primary key,

Воспроизвести я Вам уже посоветовал. ;) А про какие логи Вы пишете?

лог приложения

лог приложения

Ну а если взять запросы из них (относящиеся к одному id), и выполнить последовательно?

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

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

log_statement = all — сейчас попробую

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

Так тестирование не делается. Почти наверняка у Вас (а вовсе не в PostgreSQL) где-то ошибка. Если Вы хотите её найти, перепроверяйте всё. По крайней мере, другое отношение к проблемам куда менее плодотворно. ;)

ну, наверняка у меня

ведь писатели постгреса никогда не делают ошибок :)

ведь писатели постгреса никогда не делают ошибок :)

Делают, конечно. Просто вероятность ошибок у нас в среднем больше, чем у них. ;)

всё, кажется я понял. извините за шум. это у меня был повторный апдейт в модели, который как раз вмешивался в процесс

Ребята, помогите разобраться) Если построен индекс по столбцу A и необходимо построить индекс с конкатенацией A+B Можно ли как то указать ему в помощь первый индекс по A, чтобы, основываясь на нём, он построил A+B ?

https://www.postgresql.org/docs/10/static/indexes-multicolumn.html

https://www.postgresql.org/docs/current/static/indexes-expressional.html

Сергей, спасибо! Как делать индексы с несколькими колонками — понятно, разумеется Вопрос не в этом, а в том, чтобы при создании очередного индекса использовать информацию из другого индекса