Я думаю что второй вариант, т.к. при наличии индекса у вас будет единичный index scan.
В первом случае, вам надо сделать index scan для поиска максимального элемента во вложенном запросе, а потом еще index lookup для выборки нужного ряда.
Для раскрытия темы нужен целый отдельный цикл материалов, думается мне :)
А вообще, это еще одна затея из разряда как творчески выстрелить себе в ногу. И базе данных тоже заодно. Насколько мне известно, еще никто не придумал решений на тему передачи AST напрямую в СУБД. Дерево тоже ведь надо кодировать в какой-то формат для передачи и на принимающей стороне (внутри СУБД) преобразовывать во внутренние структуры языка Си, которые используются для хранения деревьев. Это тоже накладные расходы. Фактически — обучить базу еще одной формальной грамматике. Полученное AST все равно надо гонять через реврайт и оптимизатор, т.к. не факт что ваше нагенеренное дерево будет высокопроизводительным вариантом.
В общем, все это — очень большие заморочки с неоднозначным «профитом».
Как видите, Sort функционирует совсем не так, как Limit. Он сразу загружает все доступные данные из субплана в буфер прежде, чем что-либо возвращать. Затем он сортирует буфер с помощью алгоритма Quicksort и, наконец, возвращает первое отсортированное значение.
Весь блок данных будет отсортирован, а потом Limit из него уже будет подтягивать нужное количество. Сортировка не является ненужной, т.к. в посгресе таблицы не имеют какого-то неявного по-умолчанию установленного порядка хранения записей.
В order by можно, а вот в группировке, например, — нельзя.
Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
Здесь вы правы. Но такой продукт будет либо очень «средний по больнице», и в процессе эксплуатации все равно придется лезть в недра или звать сантехников, которые умеют в них ковыряться) Грабли на нагрузках и объемах неизбежно повылазят уже после внедрения. А до тех пор — какая-то усредненная функциональность, более-менее решаемая ORM'ом с сомнительной степенью эффективности.
Вот вы знаете, может, я просто не сталкивался с подобными проектами, но я очень подозрительно отношусь к продукту, которому надо рутинно менять одно хранилище на другое. Я имею ввиду какой-то сервис, который предоставляет услугу, считает деньги за эту услугу, разработчки каждый день решают «хотелки» от коммерции разной степени адекватности и т.д.
Поясните, свой вопрос, пожалуйста :) Про индексы можете почитать переводы наших статей про explain, там частично эта тема затрагивается. Про большие таблицы — на крупных инсталляциях проблемы с их обслуживанием могут возникнуть, зависит от совокупной ситуации на вашей базе (объем и количество таблиц, интенсивность записи и т.д.), но это тема для отдельной статьи про эксплуатацию.
Это может показаться ответом наивного фанбоя, но я вот посидел честно и подумал о своем опыте интенсивной работы с ПГ в крупных проектах и не могу вспомнить чего-то такого масштабно плохого, от чего были большие боли и страдания, по сравнению с моим опытом от работы с MySQL и NoSQL решениями. Мелких придирок могу накидать, выше коллеги, например, писали про невозможность использовать alias сложносочиненного выражения в group by. Но я это считаю больше решением из разряда bad design. Такие вещи правильно отцепить в CTE / подзапрос.
Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.
Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
У нас с саппортом Хабра, к сожалению, вышло небольшое несогласие о том, что является маркетинговым контентом в статье :) Поэтому пришлось внести корректировки и опубликовать статью повторно. К тому времени она уже уехало очень далеко в новостных лентах пользователей, поскольку Хабр осуществляет повторную публикацию с датой исходной.
Да, analyze полезно делать после заполнения какой-то таблицы или большого удаления, поскольку обновляется статистика для планировщика. Очень полезный прием, когда надо какую-то статистику обновить, например. Берем сырые данные, кладем в temporary таблицу с нужным партиционированием, строим индексы, делаем analyze и работаем с данными.
Я своих собеседников никогда не считаю по-умолчанию тупыми или невежественными. Ровно поэтому, когда коллега выше упомянул ссылку на документацию, я счел, что вы, являясь, наверняка, человеком образованным и сообразительным, найдете для себя там ответ.
Именно поэтому я оставил свой комментарий, рассчитывая на то, что вы его оцените именно с позиции человека, имеющего опыт в отрасли. Кручение «гаек» планировщика является очень опасным приемом, который в неумелых руках приводит к тому, что ранее работавшие запросы внезапно начинают дико тормозить, когда меняется статистика, собираемая базой данных, и, как следствие, выстраиваемый план запроса. То, что раньше было неэффективным и столь неэлегантным образом отключалось, внезапно стало жизненноважным для хорошей производительности.
Мой комментарий никак не касался ваших умственных способностей, профессионального опыта или стажа пребывания на Habrahabr.
Да, автор не уточнил, какие именно «гайки» он крутил, что даже очень хорошо, на мой взгляд :) Неумелое кручение этих гаек может привести к поиску подземного стука потом в приложении.
В первом случае, вам надо сделать index scan для поиска максимального элемента во вложенном запросе, а потом еще index lookup для выборки нужного ряда.
А вообще, это еще одна затея из разряда как творчески выстрелить себе в ногу. И базе данных тоже заодно. Насколько мне известно, еще никто не придумал решений на тему передачи AST напрямую в СУБД. Дерево тоже ведь надо кодировать в какой-то формат для передачи и на принимающей стороне (внутри СУБД) преобразовывать во внутренние структуры языка Си, которые используются для хранения деревьев. Это тоже накладные расходы. Фактически — обучить базу еще одной формальной грамматике. Полученное AST все равно надо гонять через реврайт и оптимизатор, т.к. не факт что ваше нагенеренное дерево будет высокопроизводительным вариантом.
В общем, все это — очень большие заморочки с неоднозначным «профитом».
Весь блок данных будет отсортирован, а потом Limit из него уже будет подтягивать нужное количество. Сортировка не является ненужной, т.к. в посгресе таблицы не имеют какого-то неявного по-умолчанию установленного порядка хранения записей.
Я подозреваю, что комментарий возник в связи с тем, что MySQL как раз-таки позволяет оперировать алиасами в group by. Я сам сталкивался с этой печалью имени MySQL-«архитекторов», когда надо было код портировать, в котом трехъэтажная «регулярка» была в виде алиаса условием для group by! Пришлось переписывать, конечно. В тупую Посгрес не дает таки вещи переносить, и это, в общем-то, хорошо.
Хотя мысль, конечно, любопытная, написать подобную статью и покопаться в шкафу со скелетами.
Вещи из разряда «GUI кривой» я не считаю недостатком базы и всех программистов приучаю работать с psql.
Именно поэтому я оставил свой комментарий, рассчитывая на то, что вы его оцените именно с позиции человека, имеющего опыт в отрасли. Кручение «гаек» планировщика является очень опасным приемом, который в неумелых руках приводит к тому, что ранее работавшие запросы внезапно начинают дико тормозить, когда меняется статистика, собираемая базой данных, и, как следствие, выстраиваемый план запроса. То, что раньше было неэффективным и столь неэлегантным образом отключалось, внезапно стало жизненноважным для хорошей производительности.
Мой комментарий никак не касался ваших умственных способностей, профессионального опыта или стажа пребывания на Habrahabr.
set enable_bitmapscan = off;