Можно было бы поставить кодекс сжатия в конце — однопоточно перед файловой системой сжимать странички. Но это бы разрушило параллелизм на месте записи на файловую систему.
Вот если бы это место распараллелить!
Кмк, можно было бы сжимать даже по несколько страниц WAL за раз.
При этом раскидывать эти пачки страниц по сжимающим воркерам. Дожидаться результата сжатия в правильном порядке и уже результат сбрасывать на диск.
И вообще тогда в памяти (в буферах WAL) можно было бы не возиться с хедерами страниц, как мне кажется. И не привязываться к границам страниц. Заголовки с чексуммами можно было бы добавлять уже к сжатым блобам, содержащим много записей.
Но это усложняет переиспользование WAL файлов: PostgreSQL сейчас выделяет место под файлы один раз, а потом их просто переименовывает и переписывает. Отвязавшись от границ страниц, будет проблематично вписываться в границы файлов.
Ну и плюс ещё обработка Switch WAL: специального хака, чтобы перейти по скорее к следующему файлу. Он используется для того, например, чтобы текущий файл можно было поскорее отправить в архив. Что очень удобно при создании резервной копии. Сейчас Switch WAL - это просто запись, сигнализирующая, что до конца текущего файла WAL не будет других записей. Если же мы начнём сжимать записи, то Switch WAL станет несколько более высокоуровневой штукой. Писатель WAL должен будет понимать, где произошёл Switch WAL, и самостоятельно переходить к следующему файлу.
Возвращаясь к теме переиспользования файлов, имя файла WAL перестанет быть таким простым. Сейчас PostgreSQL точно знает, какие LSN попадут в файл, и исходя из этого именует файл. Если же мы контейнеризируем записи, то определить заранее, с какого LSN начётся файл, очень трудно. А значит, переименовывать придётся непосредственно перед началом записи в файл.
Либо отказаться от переиспользования файлов, и писать каждый раз новые. Тогда можно и отвязаться от фиксированного размера файла (правда, у этого есть свои минусы). Скорее всего, сама запись станет медленнее: теперь кроме записи данных придётся обновлять и метаданные (о выделении места и размере). Т.е. обращений к диску на запись станет в 2-3 раза больше на каждой синхронизации. А синхронизация нужна в конце каждого коммита. Но может быть умелым пайплайнингом эту проблему можно нивелировать? Не знаю, если честно. Таких замеров не делал.
Простите за поток сознания. Долго копил, хотелось выговориться.
btw, Tarantool делает какую-то компрессию WAL именно по множеству записей. Но детали я не знаю, и в код не вчитывался.
PS. Блин, насколько бы проще было бы экспериментировать, будь в PostgreSQL потоки (threads).
6) На Go вам не нужно было бы заниматься ручным распределением по воркерам тяжёлых задач. Рантайм Гошки уже имеет достаточно хороший шедулер.
И не нужен был бы «сглаживающий прокси». Даже http сервер из стандартной библиотеки достаточно хорош.
И не нужен был бы Valkey: есть много достаточно хороших библиотек кэширования. А при сноровке, легко набросать свою. И раз один процесс на одном сервере, внешний кэш не нужен.
Но это всё, безусловно, от лукавого. Если вам ближе Python, то конечно делайте на нём. А кто-то и на Perl бы сделал, и на TCL, и не нам их осуждать.
У неё (у мыши) идеальный угол наклона под кисть. Когда расслабленно кладете ладонь на мышь, она одновременно касается всей поверхностью. И выемка под большой палец идеально расположена. Вообще не нужно напрягаться, чтобы уверенно чувствовать её в руках и управлять ею.
Конечно, это не игровая мышь: тяжеловата, и всего 150Гц сенсор. Хотя, я с нею играл в CS. Но я не профессионал в играх.
Но для работы за стационарным рабочим местом она идеальна.
Я думаю, имелось в виду init on free и/или фолианты. Могу ошибаться.
Как минимум, и коммит, породивший проблему, и коммит, починивший проблему, сделаны одним и тем же человеком - разработчиком из Oracle - с разницей в два года.
Конечно, может быть эти его изменения были протолкнуты в основное ядро, и при этом в самом Oracle каким-то образом проблемы не приносили. Но, согласитесь, это будет неожиданно и странно.
Если не используешь системные библиотеки, то нужно сертифицировать то, что используешь. А стоимость сертификации - построчная.
Если не используешь системный компилятор… не знаю, как на счёт сертификации, но под Эльбрус точно не скомпилируешь.
А как раз компиляторы под Эльбрус не на всех системах (не самых свежих, но всё ещё поддерживаемых) умеет C++17.
Да и под x86 есть ещё отечественные дистрибутивы с gcc 4.7/4.8. Поддержка вроде у этих версий дистрибутивов закончилась, да клиенты не хотят обновлять систему.
Если бы не было операции взятия модуля, вы были бы правы. Распределение суммы - действительно гауссиана. А вот распределение модуля от суммы по значительно меньшему числу - вполне себе нормальное.
Простите, но вы сейчас набросали много утверждений о моих якобы убеждениях, не имея на то веских оснований. Если решили свести диалог к навешиванию ярлыков на собеседника, то на этом наш диалог прекращается.
Вот если бы это место распараллелить!
Кмк, можно было бы сжимать даже по несколько страниц WAL за раз.
При этом раскидывать эти пачки страниц по сжимающим воркерам. Дожидаться результата сжатия в правильном порядке и уже результат сбрасывать на диск.
И вообще тогда в памяти (в буферах WAL) можно было бы не возиться с хедерами страниц, как мне кажется. И не привязываться к границам страниц. Заголовки с чексуммами можно было бы добавлять уже к сжатым блобам, содержащим много записей.
Но это усложняет переиспользование WAL файлов: PostgreSQL сейчас выделяет место под файлы один раз, а потом их просто переименовывает и переписывает. Отвязавшись от границ страниц, будет проблематично вписываться в границы файлов.
Ну и плюс ещё обработка Switch WAL: специального хака, чтобы перейти по скорее к следующему файлу. Он используется для того, например, чтобы текущий файл можно было поскорее отправить в архив. Что очень удобно при создании резервной копии. Сейчас Switch WAL - это просто запись, сигнализирующая, что до конца текущего файла WAL не будет других записей. Если же мы начнём сжимать записи, то Switch WAL станет несколько более высокоуровневой штукой. Писатель WAL должен будет понимать, где произошёл Switch WAL, и самостоятельно переходить к следующему файлу.
Возвращаясь к теме переиспользования файлов, имя файла WAL перестанет быть таким простым. Сейчас PostgreSQL точно знает, какие LSN попадут в файл, и исходя из этого именует файл. Если же мы контейнеризируем записи, то определить заранее, с какого LSN начётся файл, очень трудно. А значит, переименовывать придётся непосредственно перед началом записи в файл.
Либо отказаться от переиспользования файлов, и писать каждый раз новые. Тогда можно и отвязаться от фиксированного размера файла (правда, у этого есть свои минусы). Скорее всего, сама запись станет медленнее: теперь кроме записи данных придётся обновлять и метаданные (о выделении места и размере). Т.е. обращений к диску на запись станет в 2-3 раза больше на каждой синхронизации. А синхронизация нужна в конце каждого коммита. Но может быть умелым пайплайнингом эту проблему можно нивелировать? Не знаю, если честно. Таких замеров не делал.
Простите за поток сознания. Долго копил, хотелось выговориться.
btw, Tarantool делает какую-то компрессию WAL именно по множеству записей. Но детали я не знаю, и в код не вчитывался.
PS. Блин, насколько бы проще было бы экспериментировать, будь в PostgreSQL потоки (threads).
Я верю, что не компрессия, а copy-on-write. В Linux все ФС с компрессией используют CoW.
К тому же, LZ4 в эти ФС недавно завезли. А старые компрессоры конечно же тормозили.
Но может быть я ошибаюсь.
Для небольшой компании, вполне.
🤝
На многих ссылках в статье есть довесок:
utm_source=chatgpt.comНе знаю, как к этому относиться :-(
Минусовать не стал. Глупо бороться с тенденциями времени.
6) На Go вам не нужно было бы заниматься ручным распределением по воркерам тяжёлых задач. Рантайм Гошки уже имеет достаточно хороший шедулер.
И не нужен был бы «сглаживающий прокси». Даже http сервер из стандартной библиотеки достаточно хорош.
И не нужен был бы Valkey: есть много достаточно хороших библиотек кэширования. А при сноровке, легко набросать свою. И раз один процесс на одном сервере, внешний кэш не нужен.
Но это всё, безусловно, от лукавого. Если вам ближе Python, то конечно делайте на нём. А кто-то и на Perl бы сделал, и на TCL, и не нам их осуждать.
А можно было просто реализовать на Go!
Простите, я троллю.
У неё (у мыши) идеальный угол наклона под кисть. Когда расслабленно кладете ладонь на мышь, она одновременно касается всей поверхностью. И выемка под большой палец идеально расположена. Вообще не нужно напрягаться, чтобы уверенно чувствовать её в руках и управлять ею.
Конечно, это не игровая мышь: тяжеловата, и всего 150Гц сенсор. Хотя, я с нею играл в CS. Но я не профессионал в играх.
Но для работы за стационарным рабочим местом она идеальна.
Звезду Суворову Александру Васильевичу!
А, ниже уже utoplenick сказал, каким образом: они брали версию до и после этой проблемы. Хорошая диверсия, однако.
Я думаю, имелось в виду init on free и/или фолианты. Могу ошибаться.
Как минимум, и коммит, породивший проблему, и коммит, починивший проблему, сделаны одним и тем же человеком - разработчиком из Oracle - с разницей в два года.
Конечно, может быть эти его изменения были протолкнуты в основное ядро, и при этом в самом Oracle каким-то образом проблемы не приносили. Но, согласитесь, это будет неожиданно и странно.
В правилах дорожного движения?
Если не используешь системные библиотеки, то нужно сертифицировать то, что используешь. А стоимость сертификации - построчная.
Если не используешь системный компилятор… не знаю, как на счёт сертификации, но под Эльбрус точно не скомпилируешь.
А как раз компиляторы под Эльбрус не на всех системах (не самых свежих, но всё ещё поддерживаемых) умеет C++17.
Да и под x86 есть ещё отечественные дистрибутивы с gcc 4.7/4.8. Поддержка вроде у этих версий дистрибутивов закончилась, да клиенты не хотят обновлять систему.
Чтобы распределение остатка от деления было равномерным, сумма должна быть заметно больше величины модуля.
Возьмите модуль равный 35, и проверьте сумму 35ти rand(5). Не понравится, возьмите 70.
Ошибся: равномерное, конечно же. Спасибо, что поправили.
Если бы не было операции взятия модуля, вы были бы правы. Распределение суммы - действительно гауссиана. А вот распределение модуля от суммы по значительно меньшему числу - вполне себе нормальное.
Встроенный Visual Basic? Или что-то своё очень похожее?
Чистый Свитер?
Т.е. вы принципиально дальше первого абзаца не читаете? Сами до этого жизненного принципа дошли, или подсказал кто?
Простите, но вы сейчас набросали много утверждений о моих якобы убеждениях, не имея на то веских оснований. Если решили свести диалог к навешиванию ярлыков на собеседника, то на этом наш диалог прекращается.