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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimize common expressions in projection evaluation