From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | david(dot)g(dot)johnston(at)gmail(dot)com |
Cc: | vik(at)postgresfriends(dot)org, jacob(dot)champion(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org, er(at)xs4all(dot)nl, peter(at)eisentraut(dot)org |
Subject: | Re: Row pattern recognition |
Date: | 2024-10-25 04:04:53 |
Message-ID: | 20241025.130453.998867488192382556.ishii@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Tue, Oct 22, 2024 at 6:12 AM Vik Fearing <vik(at)postgresfriends(dot)org> wrote:
>
>>
>> On 22/10/2024 12:19, Tatsuo Ishii wrote:
>>
>> Acording to ISO/IEC 9075-2:2016 "4.21.2 Row pattern navigation operations",
>>
>> <row pattern navigation operation> evaluates a <value expression> VE
>> in a row NR, which may be different than current row CR.
>>
>> From this I think PREV(col + 1) should be interpreted as:
>>
>> 1. go to the previous row.
>> 2. evaluate "col + 1" at the current row (that was previous row).
>> 3. return the result.
>>
>> If my understanding is correct, prev(price + 1) has the same meaning
>> as prev(price) + 1.
>>
>>
>>
>> This is how I read the specification also.
>>
>>
>>
> That makes sense. Definitely much nicer to only have to write PREV once if
> the expression you are evaluating involves multiple columns. And is also
> consistent with window function "value" behavior.
Thanks to all who joined the discussion. I decided to support PREV and
NEXT in my RPR patches to allow to have multiple columns and other
expressions in their argument. e.g.
CREATE TEMP TABLE rpr1 (id INTEGER, i SERIAL, j INTEGER);
INSERT INTO rpr1(id, j) SELECT 1, g*2 FROM generate_series(1, 10) AS g;
SELECT id, i, j, count(*) OVER w
FROM rpr1
WINDOW w AS (
PARTITION BY id
ORDER BY i
ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
AFTER MATCH SKIP PAST LAST ROW
INITIAL
PATTERN (START COND+)
DEFINE
START AS TRUE,
COND AS PREV(i + j + 1) < 10
);
id | i | j | count
----+----+----+-------
1 | 1 | 2 | 3
1 | 2 | 4 | 0
1 | 3 | 6 | 0
1 | 4 | 8 | 0
1 | 5 | 10 | 0
1 | 6 | 12 | 0
1 | 7 | 14 | 0
1 | 8 | 16 | 0
1 | 9 | 18 | 0
1 | 10 | 20 | 0
(10 rows)
Attached are the v23 patches. V23 also includes the fix for the problem
pointed out by Jacob Champion and test cases from him. Thank you, Jacob.
https://www.postgresql.org/message-id/CAOYmi%2Bns3kHjC83ap_BCfJCL0wfO5BJ_sEByOEpgNOrsPhqQTg%40mail.gmail.com
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Attachment | Content-Type | Size |
---|---|---|
v23-0001-Row-pattern-recognition-patch-for-raw-parser.patch | text/x-patch | 19.9 KB |
v23-0002-Row-pattern-recognition-patch-parse-analysis.patch | text/x-patch | 11.6 KB |
v23-0003-Row-pattern-recognition-patch-rewriter.patch | text/x-patch | 4.1 KB |
v23-0004-Row-pattern-recognition-patch-planner.patch | text/x-patch | 6.7 KB |
v23-0005-Row-pattern-recognition-patch-executor.patch | text/x-patch | 54.3 KB |
v23-0006-Row-pattern-recognition-patch-docs.patch | text/x-patch | 9.7 KB |
v23-0007-Row-pattern-recognition-patch-tests.patch | text/x-patch | 50.6 KB |
v23-0008-Allow-to-print-raw-parse-tree.patch | text/x-patch | 785 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2024-10-25 04:41:00 | Re: Can rs_cindex be < 0 for bitmap heap scans? |
Previous Message | wenhui qiu | 2024-10-25 03:56:57 | Re: Changing the default random_page_cost value |