URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 133480
[ Назад ]
Исходное сообщение
"Оценка изменения производительности СУБД PostgreSQL за последние 15 лет"
Отправлено opennews , 22-Апр-24 11:53 
Райан Маркус (Ryan Marcus), разработчик экспериментального оптимизатора Bao для PostgreSQL, в котором используется  машинное обучение для оптимизации выполнения запросов, опубликовал результаты тестирования производительности штатного оптимизатора запросов  PostgreSQL. Тестирование охватывало ветки PostgreSQL, начиная с 8.4 (2009 год) и заканчивая 16 (2023 год). Производительность измерялась при помощи коллекции JOB (join order benchmark), включающей более 100 сложных запросов с большим числом операций JOIN, нацеленных на проверку различных аспектов работы оптимизатора запросов...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61042

Содержание
Сообщения в этом обсуждении
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 11:53 
Получается 13-я самая быстрая?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 12:01 
На графике только 90-й персентиль, если по нему судить то да. Но чтобы полноценно ответить надо более комплексно смотреть.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено нах. , 22-Апр-24 14:37 
в ней самый быстрый query optimizer (в общем-то было бы странно если бы с годами он становился только заметно хуже... хотя "успех" между 8 и 11 впечатляет)

Тест - синтетический, на крошечной базе целиком в памяти.

Чего оно там на самом деле тестировало - дальше разбираться незачем, поскольку если у вас производительность уперлась в query optimizer - просто оптимизируйте ручками, а не надейтесь на магию с неестественным интеллектом.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 15:10 
Завезите полноценные хинты в постгрес, будем оптимизировать ручками.

Вообще было бы неплохо иметь более низкоуровневое api, передавая постгресу напрямую план выполнения запроса. Можно даже без SQL, прямо сериализованную внутрянку. Жёстко оптимизированные запросы нужны редко, но когда нужны - это было бы намного удобнее, чем воевать с искусственным идиотом.

Для мыскля была попытка сделать (простейшее, по одной таблице) подобие в виде handlersocket, но не прижилось.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено 1 , 22-Апр-24 15:58 
Что-то там делали ребята с postgrespro в виде расширений. И чё-то я пробовал от них лет 5 назад.
Думаю, если сформулируете хотелки - они вам помогут.
Ну или не помогут, если разжирели на госзаказах.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 18:12 
В EnterpriseDB хинты есть и вполне ок. А у разработчиков Postgres принципиальная позиция не делать.

Расширением тут не обойдешься, нужно патчить.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 18:30 
Так файловый ввод-вывод и используй. Чё ты.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 23-Апр-24 05:42 
А как в MySQL передать "сериализованную внутрянку" ?
Такое впеяатление что раньше видел что-то подобное, но нагуглить не получается.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 23-Апр-24 10:06 
Не, прямо такого там нет. handlersocket был робкой попыткой, так сказать, первый подход к снаряду - "пройдись по такой табличке вот по этому индексу". Простейший tab separated протокол. Отдельный интерфейс напрямую к Innodb, в обход всего mysql-я по сути.

Можно было бы это развивать, добавив мультитабличность, ручное указание способов join-ов и т.п., но вместо этого оно сдохло.

Но даже в таком простейшем виде оно уже было очень полезно и позволяло очень шустро ходить по индексам, годилось для частых операций типа "найти юзера по ID/емейлу", работало достаточно шустро, чтобы отказаться от key value-баз сбоку. Году этак в 2011-м я так на одном mysql так строил хайлоад - шардинг по диапазонам userid + центральная база (master+slaves, shard allocation mapping + user db) на handlersocket.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 23-Апр-24 22:47 
А вы могли бы дать пример select ?

Я помню что пользовался одним примером, сильно ускоряя подсчет статистики ресторана под Друпал,
там было что-то "0x10..0xff", работало без плагинов, на mysql+galera, в те же годы.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено ptr , 23-Апр-24 11:34 
> Завезите полноценные хинты в постгрес, будем оптимизировать ручками.

А без этого религия не позволяет? Или просто лень?

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 23-Апр-24 23:32 
Для любой sql БД желание валидно. В какой-то момент роста, возникают проблемы, что штатный планировщик говно собачек и только больше проблем доставляет
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено fuggy , 22-Апр-24 18:35 
На какой ещё базе замерять скорость query optimizer если не на синтетической базе в памяти.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 11:57 
Какие приемущества этого голыша от Postgres Pro Standard?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 11:59 
https://postgrespro.ru/docs/postgrespro/16/intro-pgpro-vs-pg
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 12:14 
Оси он тоже менял или все на последнем линуксе?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено AleksK , 22-Апр-24 12:28 
Ну да и железо ставил соответсвующее каждой версии. Очевидно же что тестовая машина одна, иначе какой смысл в этих тестах.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 13:35 
(например) Фороникса это никогда не смущало, что меня всегда радовало в его сравнительных тестах теплого и мягкого.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено AleksK , 22-Апр-24 13:50 
Что-то не припомню такого у фороникса. Он если и сравнивал разные дистрибутивы то это был тест на сравнение дистрибутивов.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 13:45 
все гораздо хуже - он их крутил в виртуалке:
"inside a Docker container with Arch Linux."

был ли хост с гипервизором в горячем\холодном положении - никто не знает, как и чем еще была занята его машина в это время.

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено ыы , 22-Апр-24 13:49 
в статье есть файлик с сырыми данными. проведите анализ. покажите что девиации не системны. сможете?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 14:32 
> в виртуалке
> Docker

Вин-админ?

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено нах. , 22-Апр-24 14:39 
написано что все на последнем раче с наираспоследним компилятором (как ему удалось при этом собрать древние версии - не написано. Ну давайте предположим что они собираются. Мало ли, бывает чудес.)

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

"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено 1 , 22-Апр-24 15:56 
Ну в общем-то да, заголовок желтушный. Товарисч, решил проверить работу штатного планировщика на разных версиях ( я думаю, чтобы показать, что его планировщик с ИИ рвёт их все как тузик грелку ...).
К успеху шёл - не прокатило. Пришлось просто табличку по версиям публиковать.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Wayland на Xorg , 22-Апр-24 19:29 
Чё в итоге то 0.0.0-v12 ?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 15:05 
Ну это не единственный критерий выбора БД. Что-то же было сделано после 13 версии?
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено Аноним , 22-Апр-24 17:46 
На каком железе тестили?
Просто там же ssd появилось и оптимизатор скорее всего менялся от hdd до ssd.
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено ss , 22-Апр-24 20:55 
там же написано - вся база в памяти...
"Оценка изменения производительности СУБД PostgreSQL за после..."
Отправлено S22 , 22-Апр-24 21:31 
Ado у postgresql pro
Другой движек запрсов