потребовалось по быстрому проверить возвращает запрос что-то или нет.
думая, что select distinct /blabla limit 1 работает как select top 1 distinct /blabla в sql server запустил. жду, жду, жду, ... пока ждал, поматерился на тормоза, потом прошло времени столько, что успело дойти что этот болван делает.
ну как так-то? и нахрена так было сделано? может есть разумное объяснение такому поведению?
Здравствуйте, nikkit, Вы писали:
N>потребовалось по быстрому проверить возвращает запрос что-то или нет. N>думая, что select distinct /blabla limit 1 работает как select top 1 distinct /blabla в sql server запустил. жду, жду, жду, ... пока ждал, поматерился на тормоза, потом прошло времени столько, что успело дойти что этот болван делает. top 1 distinct — это сильно... наверное в постгресс просто не ожидали такого коварства....
Здравствуйте, nikkit, Вы писали:
N>ну как так-то? и нахрена так было сделано? может есть разумное объяснение такому поведению?
DISTINCT это автоматом GROUP BY, что тормознее даже, чем ORDER BY
По-хорошему надо SELECT EXISTS (SELECT 1 FROM ... WHERE ... LIMIT 1)
M>По-хорошему надо SELECT EXISTS (SELECT 1 FROM ... WHERE ... LIMIT 1)
я вообще всегда по возможности избегаю дистинкты. мопед не мой.
просто надо было быстро проанализировать запрос. в сиквеле после селекта тупо бы дописал топ 1 и был бы счастлив. тут во-первых писать в конце (еще раз через жопу) дак еще вот подстава )
N>я вообще всегда по возможности избегаю дистинкты. мопед не мой. N>просто надо было быстро проанализировать запрос. в сиквеле после селекта тупо бы дописал топ 1 и был бы счастлив. тут во-первых писать в конце (еще раз через жопу) дак еще вот подстава )
M>>По-хорошему надо SELECT EXISTS (SELECT 1 FROM ... WHERE ... LIMIT 1)
N>я вообще всегда по возможности избегаю дистинкты. мопед не мой. N>просто надо было быстро проанализировать запрос. в сиквеле после селекта тупо бы дописал топ 1 и был бы счастлив. тут во-первых писать в конце (еще раз через жопу) дак еще вот подстава )
То, что в MSSQL TOP 1 имеет более высокий приоритет над DISTINCT — вот это реальный трэш.
Нахрена тогда там вообще DISTINCT , так что и Postgres и Oracle в данном случае делают всё правильно и логично.
Если мне нужно первое из уникальных значений столбца — то надо сначала найти все уникальные. А не взять тупо первую строку и сделать по ней DISTINCT
--------------------------------------------------------------
Правильно заданный вопрос содержит в себе половину ответа
AN>То, что в MSSQL TOP 1 имеет более высокий приоритет над DISTINCT — вот это реальный трэш. AN>Нахрена тогда там вообще DISTINCT , так что и Postgres и Oracle в данном случае делают всё правильно и логично. AN>Если мне нужно первое из уникальных значений столбца — то надо сначала найти все уникальные. А не взять тупо первую строку и сделать по ней DISTINCT
нужно просто по-быстрому посмотреть возвращает ли чего запрос. все.
и где ты увидел логику — я хз. если вернется всего одна запись, как она может быть не дистинкт? дак нахрена же выполнять дистинкт сначала?
вот выберет он 10 записей, которые дистинкт. какую из них брать? или то что отсечет запрос не будет являться дистинкт, пока его не выполнить? ну бред же!
ну, конечно, может быть ситуация. когда на одной записи запрос падает, к примеру, да. но в этом случае я вообще не стану, к примеру, хотябы на первом шаге отладки его ограничивать. если цель типа понять что он вообще возвращает и вовзращает ли что-то.
Здравствуйте, nikkit, Вы писали:
N>потребовалось по быстрому проверить возвращает запрос что-то или нет. N>думая, что select distinct /blabla limit 1 работает как select top 1 distinct /blabla в sql server запустил. жду, жду, жду, ... пока ждал, поматерился на тормоза, потом прошло времени столько, что успело дойти что этот болван делает.
Здравствуйте, AndrewN, Вы писали: AN>То, что в MSSQL TOP 1 имеет более высокий приоритет над DISTINCT — вот это реальный трэш.
Хотелось бы увидеть пример таблицы, для которой такой приоритет операций приведёт к неверному результату.
"Реальный трэш" — это когда запрос выдаёт не то, что должен.
"Просто трэш" — это когда оптимизатор не использует какую-нибудь очевидную эквивалентность и перемалывает байты впустую.
А когда оптимизатор выбирает оптимальный способ исполнения запроса, гарантируя сохранение семантики — это как раз норма.
AN>Нахрена тогда там вообще DISTINCT , так что и Postgres и Oracle в данном случае делают всё правильно и логично. AN>Если мне нужно первое из уникальных значений столбца — то надо сначала найти все уникальные. А не взять тупо первую строку и сделать по ней DISTINCT
Вы бы ещё обиделись на то, что он при if exists(select * from tablename) не делает full table scan.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции.
Остается только разобраться с vacuum.
G>На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции. G>Остается только разобраться с vacuum.
просто в отличие от sql server, на оракле и постгресс здравый смысл и интуицию использовать бесполезно. нужно обязательно читать мануалы
Здравствуйте, gandjustas, Вы писали: G>[sarcasm]Мне кажется MySQL и эффективность запросов — понятия несовместимые. [/sarcasm]
+1. Но вот тут дотошный студент попался, после моей лекции стал вопросами донимать, типа "почему вы считаете MySQL днищем". Я бегло порылся — везде какой-то детский лепет, начиная от элементарщины типа "используйте индексы, не тащите на клиента лишнего, в случае непоняток не стесняйтесь пользоваться EXPLAIN" и заканчивая бредом вроде "не надо выбирать лишние колонки во вложенных запросах, т.к. серверу придётся тяжело". Не могу поверить, что на плаву всё ещё остался движок, неспособный продвигать проекции вниз по дереву запросов.
Вот теперь ищу источник, на который можно авторитетно сослаться
G>По MySQL все описано тут https://dev.mysql.com/doc/refman/8.0/en/optimization.html
Спасибо большое. Посмотрим повнимательнее.
Вообще, похоже, за три мажорных релиза, прошедших с тех пор, как я на него смотрел в последний раз, ребята неплохо продвинулись
Вон, даже рекурсивные CTE прикрутили.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Видимо до 8 версии (2016 год) основная стратегия работы с подзапросами была — материализация. То есть любой подзапрос в запросе превращался в таблицу в памяти или на диске, к которой применялись операторы внешнего запроса.
Поэтому любой нетривиальный запрос превращался в страшно тормозное говно. Начиная с 8 версии начали появляться другие стратегии и оптимизации, например predicate pushdown https://dev.mysql.com/doc/refman/8.0/en/derived-condition-pushdown-optimization.html
S>Вообще, похоже, за три мажорных релиза, прошедших с тех пор, как я на него смотрел в последний раз, ребята неплохо продвинулись
Есть такое, но доверия пока мало. Опыт знакомых говорит что MySQL все еще нещадно тормозит на нетривиальных запросах.
S>Вон, даже рекурсивные CTE прикрутили.
По синтаксису и семантике запросов внезапно MySQL InnoDB очень близок к MsSQL, но работает заметно хуже.
G>>На самом деле для человека, владеющего техниками оптимизации для SQL Server изучить оптимизацию для Postgres несложно, там примерно на порядок меньше вариантов операторов в плане, а множество типов индексов, которых нет в SQL Server, оптимизируют вполне конкретные функции. G>>Остается только разобраться с vacuum.
N>просто в отличие от sql server, на оракле и постгресс здравый смысл и интуицию использовать бесполезно. нужно обязательно читать мануалы
здравый смысл ? и это про базу которая три десятилетия фигачила десяток типов блокировок которые так и ничего кроме дедлоков и не дали, все равно как у оракла и пострес версионность пришлось прикручивать ?
Здравствуйте, nikkit, Вы писали:
N>просто в отличие от sql server, на оракле и постгресс здравый смысл и интуицию использовать бесполезно. нужно обязательно читать мануалы
Мануалы нужно вообще читать, и лучше перед тем, как что-то собираешься сделать.
Здравствуйте, Sinclair, Вы писали:
S>+1. Но вот тут дотошный студент попался, после моей лекции стал вопросами донимать, типа "почему вы считаете MySQL днищем". Я бегло порылся — везде какой-то детский лепет, .....
Ты прочитал лекцию "MySQL — днище," а теперь ищешь аргументы, как это обосновать?
