forum.opennet.ru - "Оценка изменения производительности СУБД PostgreSQL за последние 15 лет" (29)

"Оценка изменения производительности СУБД PostgreSQL за последние 15 лет"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Оценка изменения производительности СУБД 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.dev/opennews/art.shtml?num=61042
Ответить \| Правка \| Cообщить модератору

Оглавление

Получается 13-я самая быстрая , Аноним (1), 11:53 , 22-Апр-24, (1) +4

На графике только 90-й персентиль, если по нему судить то да Но чтобы полноценн, Аноним (4), 12:01 , 22-Апр-24, (4) +4
в ней самый быстрый query optimizer в общем-то было бы странно если бы с годами, нах. (?), 14:37 , 22-Апр-24, (12) +4

Завезите полноценные хинты в постгрес, будем оптимизировать ручками Вообще было , Аноним (15), 15:10 , 22-Апр-24, (15) +2

Что-то там делали ребята с postgrespro в виде расширений И чё-то я пробовал от , 1 (??), 15:58 , 22-Апр-24, (17)

В EnterpriseDB хинты есть и вполне ок А у разработчиков Postgres принципиальная, Аноним (15), 18:12 , 22-Апр-24, (20) +1

Так файловый ввод-вывод и используй Чё ты , Аноним (21), 18:30 , 22-Апр-24, (21)
А как в MySQL передать сериализованную внутрянку Такое впеяатление что раньше, Аноним (27), 05:42 , 23-Апр-24, (27)

Не, прямо такого там нет handlersocket был робкой попыткой, так сказать, первый, Аноним (15), 10:06 , 23-Апр-24, (28) +1

А вы могли бы дать пример select Я помню что пользовался одним примером, сильно, Аноним (27), 22:47 , 23-Апр-24, (30)

А без этого религия не позволяет Или просто лень , ptr (ok), 11:34 , 23-Апр-24, (29)
Для любой sql БД желание валидно В какой-то момент роста, возникают проблемы, ч, Аноним (31), 23:32 , 23-Апр-24, (31)

На какой ещё базе замерять скорость query optimizer если не на синтетической баз, fuggy (ok), 18:35 , 22-Апр-24, (22) +1

Какие приемущества этого голыша от Postgres Pro Standard , Аноним (2), 11:57 , 22-Апр-24, (2) –3

https postgrespro ru docs postgrespro 16 intro-pgpro-vs-pg, Аноним (2), 11:59 , 22-Апр-24, (3)

Оси он тоже менял или все на последнем линуксе , Аноним (5), 12:14 , 22-Апр-24, (5)

Ну да и железо ставил соответсвующее каждой версии Очевидно же что тестовая маш, AleksK (ok), 12:28 , 22-Апр-24, (6) +1

например Фороникса это никогда не смущало, что меня всегда радовало в его срав, Аноним (7), 13:35 , 22-Апр-24, (7) +5

Что-то не припомню такого у фороникса Он если и сравнивал разные дистрибутивы т, AleksK (ok), 13:50 , 22-Апр-24, (10) –1

все гораздо хуже - он их крутил в виртуалке inside a Docker container with Arch, Аноним (7), 13:45 , 22-Апр-24, (8) –1

в статье есть файлик с сырыми данными проведите анализ покажите что девиации н, ыы (?), 13:49 , 22-Апр-24, (9) +1
Вин-админ , Аноним (11), 14:32 , 22-Апр-24, (11)

написано что все на последнем раче с наираспоследним компилятором как ему удало, нах. (?), 14:39 , 22-Апр-24, (13)

Ну в общем-то да, заголовок желтушный Товарисч, решил проверить работу штатного, 1 (??), 15:56 , 22-Апр-24, (16) +2

Чё в итоге то 0 0 0-v12 , Wayland на Xorg (?), 19:29 , 22-Апр-24, (23)

Ну это не единственный критерий выбора БД Что-то же было сделано после 13 верси, Аноним (14), 15:05 , 22-Апр-24, (14)
На каком железе тестили Просто там же ssd появилось и оптимизатор скорее всего м, Аноним (19), 17:46 , 22-Апр-24, (19) –1

там же написано - вся база в памяти , ss (??), 20:55 , 22-Апр-24, (24)

Ado у postgresql proДругой движек запрсов, S22 (?), 21:31 , 22-Апр-24, (25)

Сообщения [Сортировка по времени | RSS]

1. "Оценка изменения производительности СУБД PostgreSQL за после..." +4 +/–

Сообщение от Аноним (1), 22-Апр-24, 11:53

Получается 13-я самая быстрая?

Ответить | Правка | Наверх | Cообщить модератору

4. "Оценка изменения производительности СУБД PostgreSQL за после..." +4 +/–

Сообщение от Аноним (4), 22-Апр-24, 12:01

На графике только 90-й персентиль, если по нему судить то да. Но чтобы полноценно ответить надо более комплексно смотреть.

Ответить | Правка | Наверх | Cообщить модератору

12. "Оценка изменения производительности СУБД PostgreSQL за после..." +4 +/–

Сообщение от нах. (?), 22-Апр-24, 14:37

в ней самый быстрый query optimizer (в общем-то было бы странно если бы с годами он становился только заметно хуже... хотя "успех" между 8 и 11 впечатляет)
Тест - синтетический, на крошечной базе целиком в памяти.
Чего оно там на самом деле тестировало - дальше разбираться незачем, поскольку если у вас производительность уперлась в query optimizer - просто оптимизируйте ручками, а не надейтесь на магию с неестественным интеллектом.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

15. "Оценка изменения производительности СУБД PostgreSQL за после..." +2 +/–

Сообщение от Аноним (15), 22-Апр-24, 15:10

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

Ответить | Правка | Наверх | Cообщить модератору

17. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от 1 (??), 22-Апр-24, 15:58

Что-то там делали ребята с postgrespro в виде расширений. И чё-то я пробовал от них лет 5 назад.
Думаю, если сформулируете хотелки - они вам помогут.
Ну или не помогут, если разжирели на госзаказах.

Ответить | Правка | Наверх | Cообщить модератору

20. "Оценка изменения производительности СУБД PostgreSQL за после..." +1 +/–

Сообщение от Аноним (15), 22-Апр-24, 18:12

В EnterpriseDB хинты есть и вполне ок. А у разработчиков Postgres принципиальная позиция не делать.
Расширением тут не обойдешься, нужно патчить.

Ответить | Правка | Наверх | Cообщить модератору

21. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (21), 22-Апр-24, 18:30

Так файловый ввод-вывод и используй. Чё ты.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

27. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (27), 23-Апр-24, 05:42

А как в MySQL передать "сериализованную внутрянку" ?
Такое впеяатление что раньше видел что-то подобное, но нагуглить не получается.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

28. "Оценка изменения производительности СУБД PostgreSQL за после..." +1 +/–

Сообщение от Аноним (15), 23-Апр-24, 10:06

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

Ответить | Правка | Наверх | Cообщить модератору

30. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (27), 23-Апр-24, 22:47

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

Ответить | Правка | Наверх | Cообщить модератору

29. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от ptr (ok), 23-Апр-24, 11:34

> Завезите полноценные хинты в постгрес, будем оптимизировать ручками.
А без этого религия не позволяет? Или просто лень?

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

31. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (31), 23-Апр-24, 23:32

Для любой sql БД желание валидно. В какой-то момент роста, возникают проблемы, что штатный планировщик говно собачек и только больше проблем доставляет

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

22. "Оценка изменения производительности СУБД PostgreSQL за после..." +1 +/–

Сообщение от fuggy (ok), 22-Апр-24, 18:35

На какой ещё базе замерять скорость query optimizer если не на синтетической базе в памяти.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

2. "Оценка изменения производительности СУБД PostgreSQL за после..." –3 +/–

Сообщение от Аноним (2), 22-Апр-24, 11:57

Какие приемущества этого голыша от Postgres Pro Standard?

Ответить | Правка | Наверх | Cообщить модератору

3. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (2), 22-Апр-24, 11:59

https://postgrespro.ru/docs/postgrespro/16/intro-pgpro-vs-pg

Ответить | Правка | Наверх | Cообщить модератору

5. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (5), 22-Апр-24, 12:14

Оси он тоже менял или все на последнем линуксе?

Ответить | Правка | Наверх | Cообщить модератору

6. "Оценка изменения производительности СУБД PostgreSQL за после..." +1 +/–

Сообщение от AleksK (ok), 22-Апр-24, 12:28

Ну да и железо ставил соответсвующее каждой версии. Очевидно же что тестовая машина одна, иначе какой смысл в этих тестах.

Ответить | Правка | Наверх | Cообщить модератору

7. "Оценка изменения производительности СУБД PostgreSQL за после..." +5 +/–

Сообщение от Аноним (7), 22-Апр-24, 13:35

(например) Фороникса это никогда не смущало, что меня всегда радовало в его сравнительных тестах теплого и мягкого.

Ответить | Правка | Наверх | Cообщить модератору

10. "Оценка изменения производительности СУБД PostgreSQL за после..." –1 +/–

Сообщение от AleksK (ok), 22-Апр-24, 13:50

Что-то не припомню такого у фороникса. Он если и сравнивал разные дистрибутивы то это был тест на сравнение дистрибутивов.

Ответить | Правка | Наверх | Cообщить модератору

8. "Оценка изменения производительности СУБД PostgreSQL за после..." –1 +/–

Сообщение от Аноним (7), 22-Апр-24, 13:45

все гораздо хуже - он их крутил в виртуалке:
"inside a Docker container with Arch Linux."
был ли хост с гипервизором в горячем\холодном положении - никто не знает, как и чем еще была занята его машина в это время.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "Оценка изменения производительности СУБД PostgreSQL за после..." +1 +/–

Сообщение от ыы (?), 22-Апр-24, 13:49

в статье есть файлик с сырыми данными. проведите анализ. покажите что девиации не системны. сможете?

Ответить | Правка | Наверх | Cообщить модератору

11. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (11), 22-Апр-24, 14:32

> в виртуалке
> Docker
Вин-админ?

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

13. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от нах. (?), 22-Апр-24, 14:39

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

16. "Оценка изменения производительности СУБД PostgreSQL за после..." +2 +/–

Сообщение от 1 (??), 22-Апр-24, 15:56

Ну в общем-то да, заголовок желтушный. Товарисч, решил проверить работу штатного планировщика на разных версиях ( я думаю, чтобы показать, что его планировщик с ИИ рвёт их все как тузик грелку ...).
К успеху шёл - не прокатило. Пришлось просто табличку по версиям публиковать.

Ответить | Правка | Наверх | Cообщить модератору

23. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Wayland на Xorg (?), 22-Апр-24, 19:29

Чё в итоге то 0.0.0-v12 ?

Ответить | Правка | Наверх | Cообщить модератору

14. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от Аноним (14), 22-Апр-24, 15:05

Ну это не единственный критерий выбора БД. Что-то же было сделано после 13 версии?

Ответить | Правка | Наверх | Cообщить модератору

19. "Оценка изменения производительности СУБД PostgreSQL за после..." –1 +/–

Сообщение от Аноним (19), 22-Апр-24, 17:46

На каком железе тестили?
Просто там же ssd появилось и оптимизатор скорее всего менялся от hdd до ssd.

Ответить | Правка | Наверх | Cообщить модератору

24. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от ss (??), 22-Апр-24, 20:55

там же написано - вся база в памяти...

Ответить | Правка | Наверх | Cообщить модератору

25. "Оценка изменения производительности СУБД PostgreSQL за после..." +/–

Сообщение от S22 (?), 22-Апр-24, 21:31

Ado у postgresql pro
Другой движек запрсов

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Оценка изменения производительности СУБД PostgreSQL за после..."	+4 +/–
Сообщение от Аноним (1), 22-Апр-24, 11:53
Получается 13-я самая быстрая?
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Оценка изменения производительности СУБД PostgreSQL за после..."	+4 +/–
	Сообщение от Аноним (4), 22-Апр-24, 12:01
	На графике только 90-й персентиль, если по нему судить то да. Но чтобы полноценно ответить надо более комплексно смотреть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Оценка изменения производительности СУБД PostgreSQL за после..."	+4 +/–
	Сообщение от нах. (?), 22-Апр-24, 14:37
	в ней самый быстрый query optimizer (в общем-то было бы странно если бы с годами он становился только заметно хуже... хотя "успех" между 8 и 11 впечатляет) Тест - синтетический, на крошечной базе целиком в памяти. Чего оно там на самом деле тестировало - дальше разбираться незачем, поскольку если у вас производительность уперлась в query optimizer - просто оптимизируйте ручками, а не надейтесь на магию с неестественным интеллектом.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	15. "Оценка изменения производительности СУБД PostgreSQL за после..."	+2 +/–
	Сообщение от Аноним (15), 22-Апр-24, 15:10
	Завезите полноценные хинты в постгрес, будем оптимизировать ручками. Вообще было бы неплохо иметь более низкоуровневое api, передавая постгресу напрямую план выполнения запроса. Можно даже без SQL, прямо сериализованную внутрянку. Жёстко оптимизированные запросы нужны редко, но когда нужны - это было бы намного удобнее, чем воевать с искусственным идиотом. Для мыскля была попытка сделать (простейшее, по одной таблице) подобие в виде handlersocket, но не прижилось.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от 1 (??), 22-Апр-24, 15:58
	Что-то там делали ребята с postgrespro в виде расширений. И чё-то я пробовал от них лет 5 назад. Думаю, если сформулируете хотелки - они вам помогут. Ну или не помогут, если разжирели на госзаказах.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Оценка изменения производительности СУБД PostgreSQL за после..."	+1 +/–
	Сообщение от Аноним (15), 22-Апр-24, 18:12
	В EnterpriseDB хинты есть и вполне ок. А у разработчиков Postgres принципиальная позиция не делать. Расширением тут не обойдешься, нужно патчить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (21), 22-Апр-24, 18:30
	Так файловый ввод-вывод и используй. Чё ты.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	27. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (27), 23-Апр-24, 05:42
	А как в MySQL передать "сериализованную внутрянку" ? Такое впеяатление что раньше видел что-то подобное, но нагуглить не получается.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	28. "Оценка изменения производительности СУБД PostgreSQL за после..."	+1 +/–
	Сообщение от Аноним (15), 23-Апр-24, 10:06
	Не, прямо такого там нет. handlersocket был робкой попыткой, так сказать, первый подход к снаряду - "пройдись по такой табличке вот по этому индексу". Простейший tab separated протокол. Отдельный интерфейс напрямую к Innodb, в обход всего mysql-я по сути. Можно было бы это развивать, добавив мультитабличность, ручное указание способов join-ов и т.п., но вместо этого оно сдохло. Но даже в таком простейшем виде оно уже было очень полезно и позволяло очень шустро ходить по индексам, годилось для частых операций типа "найти юзера по ID/емейлу", работало достаточно шустро, чтобы отказаться от key value-баз сбоку. Году этак в 2011-м я так на одном mysql так строил хайлоад - шардинг по диапазонам userid + центральная база (master+slaves, shard allocation mapping + user db) на handlersocket.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (27), 23-Апр-24, 22:47
	А вы могли бы дать пример select ? Я помню что пользовался одним примером, сильно ускоряя подсчет статистики ресторана под Друпал, там было что-то "0x10..0xff", работало без плагинов, на mysql+galera, в те же годы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от ptr (ok), 23-Апр-24, 11:34
	> Завезите полноценные хинты в постгрес, будем оптимизировать ручками. А без этого религия не позволяет? Или просто лень?
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	31. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (31), 23-Апр-24, 23:32
	Для любой sql БД желание валидно. В какой-то момент роста, возникают проблемы, что штатный планировщик говно собачек и только больше проблем доставляет
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	22. "Оценка изменения производительности СУБД PostgreSQL за после..."	+1 +/–
	Сообщение от fuggy (ok), 22-Апр-24, 18:35
	На какой ещё базе замерять скорость query optimizer если не на синтетической базе в памяти.
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору

2. "Оценка изменения производительности СУБД PostgreSQL за после..."	–3 +/–
Сообщение от Аноним (2), 22-Апр-24, 11:57
Какие приемущества этого голыша от Postgres Pro Standard?
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (2), 22-Апр-24, 11:59
	https://postgrespro.ru/docs/postgrespro/16/intro-pgpro-vs-pg
	Ответить \| Правка \| Наверх \| Cообщить модератору

5. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
Сообщение от Аноним (5), 22-Апр-24, 12:14
Оси он тоже менял или все на последнем линуксе?
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Оценка изменения производительности СУБД PostgreSQL за после..."	+1 +/–
	Сообщение от AleksK (ok), 22-Апр-24, 12:28
	Ну да и железо ставил соответсвующее каждой версии. Очевидно же что тестовая машина одна, иначе какой смысл в этих тестах.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Оценка изменения производительности СУБД PostgreSQL за после..."	+5 +/–
	Сообщение от Аноним (7), 22-Апр-24, 13:35
	(например) Фороникса это никогда не смущало, что меня всегда радовало в его сравнительных тестах теплого и мягкого.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Оценка изменения производительности СУБД PostgreSQL за после..."	–1 +/–
	Сообщение от AleksK (ok), 22-Апр-24, 13:50
	Что-то не припомню такого у фороникса. Он если и сравнивал разные дистрибутивы то это был тест на сравнение дистрибутивов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Оценка изменения производительности СУБД PostgreSQL за после..."	–1 +/–
	Сообщение от Аноним (7), 22-Апр-24, 13:45
	все гораздо хуже - он их крутил в виртуалке: "inside a Docker container with Arch Linux." был ли хост с гипервизором в горячем\холодном положении - никто не знает, как и чем еще была занята его машина в это время.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	9. "Оценка изменения производительности СУБД PostgreSQL за после..."	+1 +/–
	Сообщение от ыы (?), 22-Апр-24, 13:49
	в статье есть файлик с сырыми данными. проведите анализ. покажите что девиации не системны. сможете?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Аноним (11), 22-Апр-24, 14:32
	> в виртуалке > Docker Вин-админ?
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	13. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от нах. (?), 22-Апр-24, 14:39
	написано что все на последнем раче с наираспоследним компилятором (как ему удалось при этом собрать древние версии - не написано. Ну давайте предположим что они собираются. Мало ли, бывает чудес.) Там собака в другом порылась - мастер заголовков опеннета в очередной раз поздравляем соврамши. Тестировалась не производительность посгреза. И вот все об этом человеке.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	16. "Оценка изменения производительности СУБД PostgreSQL за после..."	+2 +/–
	Сообщение от 1 (??), 22-Апр-24, 15:56
	Ну в общем-то да, заголовок желтушный. Товарисч, решил проверить работу штатного планировщика на разных версиях ( я думаю, чтобы показать, что его планировщик с ИИ рвёт их все как тузик грелку ...). К успеху шёл - не прокатило. Пришлось просто табличку по версиям публиковать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от Wayland на Xorg (?), 22-Апр-24, 19:29
	Чё в итоге то 0.0.0-v12 ?
	Ответить \| Правка \| Наверх \| Cообщить модератору

14. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
Сообщение от Аноним (14), 22-Апр-24, 15:05
Ну это не единственный критерий выбора БД. Что-то же было сделано после 13 версии?
Ответить \| Правка \| Наверх \| Cообщить модератору

19. "Оценка изменения производительности СУБД PostgreSQL за после..."	–1 +/–
Сообщение от Аноним (19), 22-Апр-24, 17:46
На каком железе тестили? Просто там же ssd появилось и оптимизатор скорее всего менялся от hdd до ssd.
Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
	Сообщение от ss (??), 22-Апр-24, 20:55
	там же написано - вся база в памяти...
	Ответить \| Правка \| Наверх \| Cообщить модератору

25. "Оценка изменения производительности СУБД PostgreSQL за после..."	+/–
Сообщение от S22 (?), 22-Апр-24, 21:31
Ado у postgresql pro Другой движек запрсов
Ответить \| Правка \| Наверх \| Cообщить модератору