Re: Bug in row_number() optimization
От | Sergey Shinderuk |
---|---|
Тема | Re: Bug in row_number() optimization |
Дата | |
Msg-id | 56237b3b-67d9-09ba-aec2-c5fa457829fe@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Bug in row_number() optimization (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Bug in row_number() optimization
|
Список | pgsql-hackers |
On 25.11.2022 15:46, Richard Guo wrote: > Considering the 'Filter' is a strict function, marking it as > NULL would do. I think this is why this patch works. What about user-defined operators? I created my own <= operator for int8 which returns true on null input, and put it in a btree operator class. With my operator I get: depname | empno | salary | enroll_date | c1 | rn | c2 | c3 -----------+-------+--------+-------------+----+----+----+---- personnel | 5 | 3500 | 2007-12-10 | 2 | 1 | 2 | 2 sales | 3 | 4800 | 2007-08-01 | 3 | 1 | 3 | 3 sales | 4 | 4800 | 2007-08-08 | 3 | | | 3 (3 rows) Admittedly, it's weird that (null <= 1) evaluates to true. But does it violate the contract of the btree operator class or something? Didn't find a clear answer in the docs. -- Sergey Shinderuk https://postgrespro.com/
В списке pgsql-hackers по дате отправления: