| From: | Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Rowley <drowley(at)postgresql(dot)org> |
| Subject: | Re: Bug in row_number() optimization |
| Date: | 2022-11-25 16:01:09 |
| Message-ID: | 56237b3b-67d9-09ba-aec2-c5fa457829fe@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-11-25 16:13:29 | Re: Non-decimal integer literals |
| Previous Message | Ted Yu | 2022-11-25 15:56:13 | checking rd_rules in RelationBuildDesc |