@Kilor а вариант запускать limit 1000 от последней обновленной записи не рассматривал?
Так пейджинг можно сделать. Только ему надо быстро предыдущее значение узнавать, а от него limit без offset можно запускать. Там лучше всего pk подходит, правда.
Честно говоря я уже запутался что Вам понятно, а что нет.
Коротко.
Мне дали запрос и предложили его изменить. Изменить ТОЛЬКО запрос. Поэтому я накрутил логики и заодно предложил, как добиться производительности другими способами.
На что получил, как я думаю, не адекватный ответ, про мешающий индекс.
Все мои способы были с комментариями. С плюсами и минусами. Так, например, глобального PK PostgreSQL делать не умеет.
Но это все было просто проигнорировано.
Плюс, если системе понадобится искать что-нибудь по ServiceDate, вы прозреете насколько партиции все испортят.
Не знаю про какой вы ServiceDate, но есть partition pruning. Да и задачи такой не было.
Я так понял вы рассматриваете мой код применительно к продакшену, не понятно к какому. Но делать этого не нужно, потому что это было странное тестовое задание не понятно что проверяющие.
Теперь я вас удивлю и надеюсь все встанет на свои места и будет понятно, почему я написал эту статью.
Итак. В файле, который содержал решение были еще несколько вариантов. Там были еще парочка индексов, партиционирование (о нем, кстати, тут никто не подумал) и другие предложения. Т.е. вместо этих всех рекурсией и т.д. был тупой индекс, который содержал только не обработанные элементы очереди. Партиции тут вообще лучше всего подходят, т.к. не требуют индексов. Но все это было проигнорировано, а мои решения были названы сумбурными.
Что я делал дак то, что в отсутствии четкого задания я накидывал разные варианты.
Я хочу вас спросить. Вы видели запрос с рекурсией? Понимаете, чем он отличается от того для которого потребовалось изменить данные? Понимаете, что эти запросы вернут одно и то же? Я только до сих пор не понимаю, как действует мнимый обработчик. Поэтому варианта основных два.
А если имеется день без записей?
А если кто-то другой загребет ту же запись? Тоже как бы по заданию можно предположить?
А если обработает, а признак не вернёт? Тоже по заданию...
Можно вас попросить проголосовать за неточность ТЗ?
Но ведь оно - имеется, из песни слова не выбросишь.
Там надо ускорить запрос, а не писать реальную очередь.
Не делал дополнительных и супер очевидных индексов только потому что в задании сказано изменить запрос. Изменить САМ запрос, чтобы он стал быстрей. Да и как вы, вероятно уже поняли, индексы нужно было не создавать, а убивать :) И последнее. Работа была 100% такая, что решение ускорить запрос индексом железобетонно не прокатило бы. Слишком уж просто.
Ну и кстати, в решении которое я им послал в пунктах ниже, были и индексы, и инклуды и даже партиции. Согласитесь, с партициями и индексы не нужны. Но все это было проигнорировано.
WITH TIES
Бог с ним. По настоящему это отношение к делу не имеет.
Ну да. С таким индексом никаких дополнительных плясок в коде не нужно. Это намного больше похоже на обработку очереди. Только в задании сказано тупо поменять запрос. Ой. Индекс выключить. Ой. Бог знает что сделать с дырками после обработки.
Я на самом деле не знаю, что было правильным ответом. Вот честно. Все что они мне сказали я тут привел. Но вот про мешающий индекс точно звучало. А я со стула упал.
Итак. fetch имеет смысл только with ties, который тут не нужен. Я, конечно, пошел и перечитал. Не уверен я, что даже вы прям все-все детали документации помните. Но суть моей статьи вообще не в этом. Вы б лучше, что-нибудь по делу сказали, чем цепляться за мелочи.
Я такой им давал. Проигнорировали
Статья про как избежать сканирования записей до 1000. На это есть два способа. Тот что в статье (limit 1) и с pk + limit 1000
@Kilor а вариант запускать limit 1000 от последней обновленной записи не рассматривал?
Так пейджинг можно сделать. Только ему надо быстро предыдущее значение узнавать, а от него limit без offset можно запускать. Там лучше всего pk подходит, правда.
Ой. Я не нашел ничего сложного. Код достаточно простой
Честно говоря я уже запутался что Вам понятно, а что нет.
Коротко.
Мне дали запрос и предложили его изменить. Изменить ТОЛЬКО запрос. Поэтому я накрутил логики и заодно предложил, как добиться производительности другими способами.
На что получил, как я думаю, не адекватный ответ, про мешающий индекс.
Все мои способы были с комментариями. С плюсами и минусами. Так, например, глобального PK PostgreSQL делать не умеет.
Но это все было просто проигнорировано.
Не знаю про какой вы ServiceDate, но есть partition pruning. Да и задачи такой не было.
Я так понял вы рассматриваете мой код применительно к продакшену, не понятно к какому. Но делать этого не нужно, потому что это было странное тестовое задание не понятно что проверяющие.
Вот теперь я вас понял. Спасибо за ваше мнение.
Теперь я вас удивлю и надеюсь все встанет на свои места и будет понятно, почему я написал эту статью.
Итак. В файле, который содержал решение были еще несколько вариантов. Там были еще парочка индексов, партиционирование (о нем, кстати, тут никто не подумал) и другие предложения. Т.е. вместо этих всех рекурсией и т.д. был тупой индекс, который содержал только не обработанные элементы очереди. Партиции тут вообще лучше всего подходят, т.к. не требуют индексов. Но все это было проигнорировано, а мои решения были названы сумбурными.
Что я делал дак то, что в отсутствии четкого задания я накидывал разные варианты.
Дак, что да или нет? В целом спич понятен, но нога букав.
Не знаю. Наверно, потому что это просто тестовое задание
Эх, не было у меня интервью. А в текстовом файле с решением были и индексы и партиции и еще много чего. Но все это было проигнорировано.
Отвечали мне в телеге. Все что ответили я описал своими словами
Я хочу вас спросить. Вы видели запрос с рекурсией? Понимаете, чем он отличается от того для которого потребовалось изменить данные? Понимаете, что эти запросы вернут одно и то же? Я только до сих пор не понимаю, как действует мнимый обработчик. Поэтому варианта основных два.
А если кто-то другой загребет ту же запись? Тоже как бы по заданию можно предположить?
А если обработает, а признак не вернёт? Тоже по заданию...
Можно вас попросить проголосовать за неточность ТЗ?
Там надо ускорить запрос, а не писать реальную очередь.
Не делал дополнительных и супер очевидных индексов только потому что в задании сказано изменить запрос. Изменить САМ запрос, чтобы он стал быстрей. Да и как вы, вероятно уже поняли, индексы нужно было не создавать, а убивать :) И последнее. Работа была 100% такая, что решение ускорить запрос индексом железобетонно не прокатило бы. Слишком уж просто.
Ну и кстати, в решении которое я им послал в пунктах ниже, были и индексы, и инклуды и даже партиции. Согласитесь, с партициями и индексы не нужны. Но все это было проигнорировано.
Бог с ним. По настоящему это отношение к делу не имеет.
id в include?
Ну да. С таким индексом никаких дополнительных плясок в коде не нужно. Это намного больше похоже на обработку очереди. Только в задании сказано тупо поменять запрос. Ой. Индекс выключить. Ой. Бог знает что сделать с дырками после обработки.
Я на самом деле не знаю, что было правильным ответом. Вот честно. Все что они мне сказали я тут привел. Но вот про мешающий индекс точно звучало. А я со стула упал.
Итак. fetch имеет смысл только with ties, который тут не нужен. Я, конечно, пошел и перечитал. Не уверен я, что даже вы прям все-все детали документации помните. Но суть моей статьи вообще не в этом. Вы б лучше, что-нибудь по делу сказали, чем цепляться за мелочи.
FETCH в продакшене не видел ни разу, потому что есть новый limit
В задании ничего не сказано про специфику обработки. А я уж поверьте наелся очередей и прекрасно понимаю, что могут быть дырки.
Если читать мою статью внимательно, то у меня есть вариант, который это учитывает.
Про скрипт. Мне не хотелось выкладывать задание полностью. По понятным надеюсь причинам
Вы, конечно совершенно правы! Такой индекс всегда будет "в форме".
Но, в задании написано изменить сам запрос. И я чуть с дуба не рухнул, когда узнал, что изменить запрос у них означает выключить индекс вообще :)
Спасибо!
Особенно за стиль письма. Бывает простецкую вещь человек описывает и ничего не понятно. А тут хоть и многа букав а все-равно все понял.
По моему опыту чем меньше всякой этой наследственности и разделений тем проще и разрабатывать и поддерживать.
Делить надо грамотно только большие куски.
Главное все же тесты иметь хоть какие-то.
Я вот вообще мало что понял. Кроме того, что нечто довольно круто.
Да и вообще железные шканты - нет ни в коем случае.
Где? Какие шканты. Нахрена они вообще!? Согласитесь ничего не понятно.