Спасибо большое за комментарии! Постарался убрать все неточности по тексту, поменял тестовые запросы и перезапустил весь тест заново. Идея действительно была показать как работают SELECT DISTINCT или COUNT DISTINCT в разных СУБД. Что MySQL из коробки работает очень хорошо на столбце в любой кадинальностью, и что можно оптимизировать в PostgreSQL и MS SQL Server, чтобы добиться схожего результата.
Насчет методики все-таки не соглашусь. Все равно все запросы надо запускать из какого-то клиента к СУБД (например, стандартной консольной утилите локально). Это, конечно, даст более чистые результаты, но они не будут кардинально отличаться от тех, которые будут получены общим внешним клиентом. Тут задача была именно показать кардинальное снижение времени выполнения, если запускать на колонках с низкой кардинальностью в MySQL, и что такого снижения нет в остальных двух СУБД и там надо действовать по-другому, чтобы добиться ускорения.
Как раз я не ставил задачу затюнить каждую СУБД по максимуму под конкретный запрос. Поэтому были взяты Docker контейнеры с настройками по умолчанию. Да и я сомневаюсь, что кэш в этом запросе даст какой-то другой результат. Первые 5 запусков я делал холостыми, потому что на них как раз время может сильно варьироваться. Само время выполнения запроса тут вторично, важно скорее, что loose scan или его имитация дает качественно другое время выполнения. А то, что MS SQL что-то выполняет за 2 секунды, а PostgreSQL за одну, например, не суть важно, потому что в продакшене конечно все будет по-другому. Тут важнее смотреть не столько разницу между СУБД, сколько в пределах одной СУБД.
Согласен, возможно, стоило чуть более подробно описать, что конкретно делалось. Однако запросы, которые выполнялись и скрипт инициализации был приведен. Это обычные запросы вида SELECT A, COUNT(*) FROM TABLE GROUP BY A, и он действительно будет возвращать только уникальные значения из колонки A. Дополнительный COUNT(*) был сделан, чтобы сократить выдачу из запроса только одной строкой, чтобы исключить из сравнения время, которое уходит на передачу данных из сервера до клиента. Опять же для максимальной честности результатов, потому что один запрос будет выдавать 100 тыс. строк, а другой только 10. Довольно распространенные запросы во всех СУБД, с которыми можно столкнуться. Цель статьи была подсветить, что такие запросы могут выполняться значительно быстрее, если количество уникальных значений мало. И вот MySQL и другие СУБД могут делать это автоматически из коробки, однако для PostgreSQL и MS SQL Server я привел примеры, как это тоже можно оптимизировать.
Я конечно с девушкой подкаст не слышал, но об этой версии могу сказать так: голос отличный, но чтение идет слишком быстро… приходиться напряженнос вслушиваться. Нельзя ли чуть-чуть помедленнее?
Спасибо большое за комментарии! Постарался убрать все неточности по тексту, поменял тестовые запросы и перезапустил весь тест заново. Идея действительно была показать как работают SELECT DISTINCT или COUNT DISTINCT в разных СУБД. Что MySQL из коробки работает очень хорошо на столбце в любой кадинальностью, и что можно оптимизировать в PostgreSQL и MS SQL Server, чтобы добиться схожего результата.
Насчет методики все-таки не соглашусь. Все равно все запросы надо запускать из какого-то клиента к СУБД (например, стандартной консольной утилите локально). Это, конечно, даст более чистые результаты, но они не будут кардинально отличаться от тех, которые будут получены общим внешним клиентом. Тут задача была именно показать кардинальное снижение времени выполнения, если запускать на колонках с низкой кардинальностью в MySQL, и что такого снижения нет в остальных двух СУБД и там надо действовать по-другому, чтобы добиться ускорения.
Если вы можете подсказать какие-то настройки, которые могут сделать сравнение еще более честным, буду вам очень благодарен.
Как раз я не ставил задачу затюнить каждую СУБД по максимуму под конкретный запрос. Поэтому были взяты Docker контейнеры с настройками по умолчанию. Да и я сомневаюсь, что кэш в этом запросе даст какой-то другой результат. Первые 5 запусков я делал холостыми, потому что на них как раз время может сильно варьироваться. Само время выполнения запроса тут вторично, важно скорее, что loose scan или его имитация дает качественно другое время выполнения. А то, что MS SQL что-то выполняет за 2 секунды, а PostgreSQL за одну, например, не суть важно, потому что в продакшене конечно все будет по-другому. Тут важнее смотреть не столько разницу между СУБД, сколько в пределах одной СУБД.
Согласен, возможно, стоило чуть более подробно описать, что конкретно делалось. Однако запросы, которые выполнялись и скрипт инициализации был приведен. Это обычные запросы вида SELECT A, COUNT(*) FROM TABLE GROUP BY A, и он действительно будет возвращать только уникальные значения из колонки A. Дополнительный COUNT(*) был сделан, чтобы сократить выдачу из запроса только одной строкой, чтобы исключить из сравнения время, которое уходит на передачу данных из сервера до клиента. Опять же для максимальной честности результатов, потому что один запрос будет выдавать 100 тыс. строк, а другой только 10. Довольно распространенные запросы во всех СУБД, с которыми можно столкнуться. Цель статьи была подсветить, что такие запросы могут выполняться значительно быстрее, если количество уникальных значений мало. И вот MySQL и другие СУБД могут делать это автоматически из коробки, однако для PostgreSQL и MS SQL Server я привел примеры, как это тоже можно оптимизировать.