Я планирую попробовать воспроизвести этот результат используя "динамические" bpf пробы (uprobe/uretprobe), но в этот раз это будет существенно сложнее потому что соответствующие функции "инлайнятся", см. static inline void pgstat_report_wait_start(uint32 wait_event_info)
(Прим. переводчика) Если вы решите повторить этот процесс, то репозиторий (http:// github.com/FritsHoogland/postgres-bpftrace ) содержит пару неточностей
Ну и RUN git apply wait_event.patch не работает, т.к. код Postgres уже ушёл вперёд, можно посмотреть что сделано и проделать тоже самое своими руками, для работоспособности кода этой статьи, впрочем, это не критично ;)
Согласен можно было и попроще пример создать, синтетику писал по горячим следам и публиковал в своём блоге, а это уже перевод (не стал переделывать).
По поводу зачем : это не просто "бесконечный" запрос, а бесконечный запрос который не потребляет ничего кроме CPU и не падает. Можно использовать например для исследования честности CPU scheduling'a для resource manager'a и т.п.
Добрый день, Намеренно не стал рассматривать разнообразные случаи, возможно можно и с "=" получить экспоненциальную сложность (ну например данные таковы что на каждом шаге кол-во данных подпадающих под условие равенства удваивается/утраивается ...) .
В чём я вижу "примечательность" этого случая.
Это пример чисто CPU нагрузки, фактически без потребления IO или RAM(PGA).
Это демонстрация того что примитивное понимание исполнения плана, а именно выполняется полностью сначала один шаг, затем переходим к следующему - не всегда верно.
Спасибо! Добавлю.
Я планирую попробовать воспроизвести этот результат используя "динамические" bpf пробы (uprobe/uretprobe), но в этот раз это будет существенно сложнее потому что соответствующие функции "инлайнятся", см.
static inline void pgstat_report_wait_start(uint32 wait_event_info)(Прим. переводчика) Довольно детальное описание usdt probe можно найти здесь:
https://leezhenghui.github.io/linux/2019/03/05/exploring-usdt-on-linux.html#heading-usdt
(Прим. переводчика) Если вы решите повторить этот процесс, то репозиторий (http:// github.com/FritsHoogland/postgres-bpftrace ) содержит пару неточностей
https://github.com/FritsHoogland/postgres-bpftrace/blob/main/docker/Dockerfile.postgres_17_modified
содержит команду COPY wait_event.patch . на вашей хост машине вряд ли есть этот файл, так что лучше заменить на внутреннее копирование, что то вроде
RUN cp ...
https://github.com/FritsHoogland/postgres-bpftrace/blob/main/query-analyzer.bt содержит некорректные пути (usdt:/usr/lib/postgresql/15/bin/postgres) а мы инсталлируем с префиксом (--prefix=/usr/local/pgsql) так что надо заменить на (usdt:/usr/local/pgsql/bin/postgres)
Ну и RUN git apply wait_event.patch не работает, т.к. код Postgres уже ушёл вперёд,
можно посмотреть что сделано и проделать тоже самое своими руками, для работоспособности кода этой статьи, впрочем, это не критично ;)
Привет Саян!
Согласен можно было и попроще пример создать, синтетику писал по горячим следам и публиковал в своём блоге, а это уже перевод (не стал переделывать).
По поводу зачем : это не просто "бесконечный" запрос, а бесконечный запрос который не потребляет ничего кроме CPU и не падает. Можно использовать например для исследования честности CPU scheduling'a для resource manager'a и т.п.
Добрый день,
Намеренно не стал рассматривать разнообразные случаи, возможно можно и с "=" получить экспоненциальную сложность (ну например данные таковы что на каждом шаге кол-во данных подпадающих под условие равенства удваивается/утраивается ...) .
В чём я вижу "примечательность" этого случая.
Это пример чисто CPU нагрузки, фактически без потребления IO или RAM(PGA).
Это демонстрация того что примитивное понимание исполнения плана, а именно выполняется полностью сначала один шаг, затем переходим к следующему - не всегда верно.