В исследовании сравнивались реализация lock-free списка с традиционным списком на блокировках, и оба варианта использовали dsa для аллокации отдельных элементов. Т.е. сравнение было "apples to apples" и оно показало именно влияние lock-free реализации самого списка. Тот факт, что dsa внутри себя использует блокировки, был известен и принят как часть прототипа.
В случае если предлагаемый подход получит развитие в рамках другой задачи, выдвигающей более серьезные требования к производительности (в отличие от задачи отслеживания брошенных файлов), то, возможно, этот нюанс будет переработан и улучшен.
Измерение времени выполнения происходило непосредственно внутри тестовой функции (через GetCurrentTimestamp) как дельта между моментами времени непосредственно перед стартом цикла вставки/удаления элементов списка и сразу после завершения цикла. В таком виде синхронизация бекендов не требовалась.
Относительно "поделиться с сообществом" - мы исследовали этот подход в рамках MVP для нашей задачи. Мы пока что не искали подходящего кандидата из фич ванильного постгреса, где этот функционал мог бы пригодиться. Если есть идеи, то будем рады их рассмотреть и, если результаты прототипирования будут воодушевляющими, то можно рассмотреть вариант предложения наработок сообществу.
Транзакции могут создавать таблицы (и, как следствие, файлы данных) как они сочтут нужным и пока хватает ресурсов, и мы должны трекать создаваемые элементы. Вариант с использованием буфера фиксированного размера неизменно поднимает вопросы:
сколько изначально отводить памяти под список для каждого бекенда. Профили работы разных бекендов могут сильно отличаться - кто-то создает много объектов, кто-то - нет.
что делать при исчерпании этого буфера. Перетирание содержимого является неприемлемым вариантом, останавливать выполнение транзакции пока читатель не извлечет текущие элементы или расширять буфер и перекладывать элементы - также медленные и поэтому плохие варианты.
Поэтому мы сделали выбор в сторону динамического выделения/освобождения, которую нам предоставляет dsa. В нашем случае память выделяется (с помощью dsa_allocate) под каждый элемент списка индивидуально при вставке элемента. Переноса данных не происходит.
Операция вставки возвращает бекенду указатель (локальный для данного бекенда адрес, полученный через dsa_get_address) на вставленный элемент, чтобы бекенд смог сохранить его в своей локальной памяти и, позже, использовать его для удаления из списка. Операция удаления на вход ожидает этот указатель на элемент, и, имея этот указатель, нет необходимости проходить весь список в поисках элемента. Сама операция удаления имеет константное время выполнения.
Да, этот подход подразумевает работу только с одним процессом-писателем. Об этом есть упоминание в секции с конструктивными ограничениями подхода - "Для каждого списка relfilenode существует строго один выделенный процесс записи (backend-процесс) и один выделенный процесс чтения (checkpointer)".
В исследовании сравнивались реализация lock-free списка с традиционным списком на блокировках, и оба варианта использовали dsa для аллокации отдельных элементов. Т.е. сравнение было "apples to apples" и оно показало именно влияние lock-free реализации самого списка. Тот факт, что dsa внутри себя использует блокировки, был известен и принят как часть прототипа.
В случае если предлагаемый подход получит развитие в рамках другой задачи, выдвигающей более серьезные требования к производительности (в отличие от задачи отслеживания брошенных файлов), то, возможно, этот нюанс будет переработан и улучшен.
Если говорить именно про физическое удаление из структуры списка, то да.
Измерение времени выполнения происходило непосредственно внутри тестовой функции (через GetCurrentTimestamp) как дельта между моментами времени непосредственно перед стартом цикла вставки/удаления элементов списка и сразу после завершения цикла. В таком виде синхронизация бекендов не требовалась.
Относительно "поделиться с сообществом" - мы исследовали этот подход в рамках MVP для нашей задачи. Мы пока что не искали подходящего кандидата из фич ванильного постгреса, где этот функционал мог бы пригодиться. Если есть идеи, то будем рады их рассмотреть и, если результаты прототипирования будут воодушевляющими, то можно рассмотреть вариант предложения наработок сообществу.
Транзакции могут создавать таблицы (и, как следствие, файлы данных) как они сочтут нужным и пока хватает ресурсов, и мы должны трекать создаваемые элементы.
Вариант с использованием буфера фиксированного размера неизменно поднимает вопросы:
сколько изначально отводить памяти под список для каждого бекенда. Профили работы разных бекендов могут сильно отличаться - кто-то создает много объектов, кто-то - нет.
что делать при исчерпании этого буфера. Перетирание содержимого является неприемлемым вариантом, останавливать выполнение транзакции пока читатель не извлечет текущие элементы или расширять буфер и перекладывать элементы - также медленные и поэтому плохие варианты.
Поэтому мы сделали выбор в сторону динамического выделения/освобождения, которую нам предоставляет dsa. В нашем случае память выделяется (с помощью dsa_allocate) под каждый элемент списка индивидуально при вставке элемента. Переноса данных не происходит.
Операция вставки возвращает бекенду указатель (локальный для данного бекенда адрес, полученный через dsa_get_address) на вставленный элемент, чтобы бекенд смог сохранить его в своей локальной памяти и, позже, использовать его для удаления из списка. Операция удаления на вход ожидает этот указатель на элемент, и, имея этот указатель, нет необходимости проходить весь список в поисках элемента. Сама операция удаления имеет константное время выполнения.
Да, этот подход подразумевает работу только с одним процессом-писателем. Об этом есть упоминание в секции с конструктивными ограничениями подхода - "Для каждого списка relfilenode существует строго один выделенный процесс записи (backend-процесс) и один выделенный процесс чтения (checkpointer)".