я думаю, что имел ввиду именно диск как штука, которая работает медленно, но гарантирует надежность записи. дата файл это или что-то еще не особо имеет значения.
Есть вопрос, а WAL не влияет на скорость применения закомиченных изменений в таблицу? Сталкивался со странным поведением PG при повышенной нагрузке с постоянным поднятием транзакций, что изменения закоммиченные одной транзакцией становятся "видимы" в других коннектах/транзакциях только через 200-300мс. Было весело потом все это разгребать) Уровни изоляции вроде не причем - конкуренция была между update и select for update
Классный подкаст! Не останавливайтесь)
потрясающе, очень интересно и качественно. Отдельно хочу заметить что очень хорошо поставлен голос и речь, ты этим где-то занимался специально?
ой спасибочки!!!! нет, я не занимался ничем, просто иногда текст прям прописываю, а иногда на монтаже убираю всякое "aaa", "нууу".
6:00 - что ты имеешь ввиду под "можем записывать грязные страницы на диск"? Имеешь ввиду, записывать грязные страницы в дата файл?
Просто, всё в базе- это "диск". За исключением, может быть, tail, который подозреваю живёт в памяти
я думаю, что имел ввиду именно диск как штука, которая работает медленно, но гарантирует надежность записи. дата файл это или что-то еще не особо имеет значения.
Есть вопрос, а WAL не влияет на скорость применения закомиченных изменений в таблицу?
Сталкивался со странным поведением PG при повышенной нагрузке с постоянным поднятием транзакций, что изменения закоммиченные одной транзакцией становятся "видимы" в других коннектах/транзакциях только через 200-300мс. Было весело потом все это разгребать)
Уровни изоляции вроде не причем - конкуренция была между update и select for update
в итоге получилось соптимизировать?
@@apkhmv нет, просто отрефачили архитектуру так, чтобы не было необходимости в транзакциях
Видимо, СУБД при вашей нагрузке не может чаще опрашивать статус "закоммиченности"