Re: Bug in row_number() optimization
От | David Rowley |
---|---|
Тема | Re: Bug in row_number() optimization |
Дата | |
Msg-id | CAApHDvrDteMo9N5am94ytNSJ2PYBsUmp3qCdXSWkjp261EggJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in row_number() optimization (Sergey Shinderuk <s.shinderuk@postgrespro.ru>) |
Список | pgsql-hackers |
On Mon, 28 Nov 2022 at 22:59, Sergey Shinderuk <s.shinderuk@postgrespro.ru> wrote: > > On 28.11.2022 03:23, David Rowley wrote: > > On Sat, 26 Nov 2022 at 05:19, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> It's pretty unlikely that this would work during an actual index scan. > >> I'm fairly sure that btree (and other index AMs) have hard-wired > >> assumptions that index operators are strict. > > > > If we're worried about that then we could just restrict this > > optimization to only work with strict quals. > > Not sure this is necessary if btree operators must be strict anyway. I'd rather see the func_strict() test in there. You've already demonstrated you can get wrong results with a non-strict operator. I'm not disputing that it sounds like a broken operator class or not. I just want to ensure we don't leave any holes open for this optimisation to return incorrect results. David
В списке pgsql-hackers по дате отправления: