Да. И зачем Вы его написали? ;) Я тут уже неоднократно писал, кажется — PostgreSQL не занимается устранением "идиотизмов" в запросах "специально" (если что-то такое устраняется, то только как побочный эффект каких-то более "мощных" оптимизаций). И да, это твёрдая (и совершенно правильная, IMNSHO) позиция проекта, если что.
согласен, что идиотизм, но поведение странное. Поэтому, возможны, и коде есть странности.
Ничего странного, "код" не занимается и не будет заниматься поиском повторений условий.
А можете подсказать, он начинает рассматривать where из нутри или с наружи сразу?
Хмм... в смысле? Каждая WHERE разбирается на clauses (вроде "o.sys_period @> sys_time()" или "agreement_id = 1736"). Далее каждая обрабатывается / привязывается к одному relation (restriction clause) или нескольким (join clause). И они отдельно "проталкиваются" и т.п.
вот для второго запроса, сразу разбирается вложенный WHERE или наружный?
Вообще-то, это не имеет никакого значения. ;) Но если любопытно, то в процессе планирования сначала обрабатывается внутренний.
а если результат внутреннего запроса материализуется отдельно, при условии что там набор данных небольшой, разве не быстрее обработается дублирующее условие?
А я предпологал, что внешний. Тогда ещё предположу, что использование индекса по пути меняется с BitmapHeapScan на IndexScan (когда до наружного WHERE доходит) да, было любопытно. Спасибо. Даже большое Спасибо за ваше время.
Я отвечал совсем не об этом.
Я отвечал про планирование, учтите. Поэтому не имеет значения в этом случае, внутренний или внешний — план получится тот же. И разница там именно в том, что условие получается совсем другое...
я понимаю, "я только спросить". :)
А вообще, просто ради любопытства / на будущее — лучше бы self-reproducible test cases показывать в нетривиальных случаях. Или хоть \d каждой участвующей таблицы, \sf каждой участвующей функции и т.п. ;)
Обсуждают сегодня