Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options
Tatsuo Ishii <ishii@postgresql.org>
From: Tatsuo Ishii <ishii@postgresql.org>
To: ojford@gmail.com
Cc: vik@postgresfriends.org, pgsql-hackers@postgresql.org,
tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, david@fetter.org,
krasiyan@gmail.com
Date: 2025-01-19T23:55:17Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix coding style with "else".
- 20628b62e46e 19 (unreleased) landed
-
Fix multi WinGetFuncArgInFrame/Partition calls with IGNORE NULLS.
- 2d7b247cb414 19 (unreleased) landed
-
Fix Coverity issue reported in commit 2273fa32bce.
- dd766a441d69 19 (unreleased) landed
-
Use ereport rather than elog in WinCheckAndInitializeNullTreatment.
- 5f3808646f67 19 (unreleased) landed
-
Avoid uninitialized-variable warnings from older compilers.
- 71540dcdcb22 19 (unreleased) cited
-
Fix Coverity issues reported in commit 25a30bbd423.
- 2273fa32bce7 19 (unreleased) landed
-
Improve EXPLAIN's display of window functions.
- 8b1b342544b6 18.0 cited
-
Automatically generate node support functions
- 964d01ae90c3 16.0 cited
Attachments
- (unnamed) (text/plain)
Thanks for updating the patch. >> It seems you allow to use IGNORE NULLS for all window functions. If >> the case, you should explicitely stat that in the docs. Otherwise >> users will be confused because; > > The latest version restricts it to lag, lead, first_value, last_value, > and nth_value. We can extend it in a subsequent patch if there's > demand? The restriction is required by the SQL standard. So I don't think we need to extend to other window functions. >> I take a look at the patch and noticed that following functions have >> no comments on what they are doing and what are the arguments. Please >> look into other functions in nodeWindowAgg.c and add appropriate >> comments to those functions. > > Latest version has more comments and should be in the standard coding style. Still I see non standard coding stiles and indentations. See attached patch for nodeWindowAgg.c, which is fixed by pgindent, for example. (Other files may need fixing too). >> I also notice that you have an array in memory which records non-null >> row positions in a partition. The position is represented in int64, >> which means 1 entry consumes 8 bytes. If my understanding is correct, >> the array continues to grow up to the partition size. Also the array >> is created for each window function (is it really necessary?). I worry >> about this because it might consume excessive memory for big >> partitions. > > It's an int64 because it stores the abs_pos/mark_pos which are int64. > Keeping an array for each function is needed for the mark optimization > to work correctly. Ok. Here are some comments regarding the patch: (1) I noticed that ignorenulls_getfuncarginframe() does not take account EXCLUSION frame options. The code path is in WinGetFuncArgInFrame(): /* * Account for exclusion option if one is active, but advance only * abs_pos not mark_pos. This prevents changes of the current * row's peer group from resulting in trying to fetch a row before * some previous mark position. : : I guess ignorenulls_getfuncarginframe() was created by modifying WinGetFuncArgInFrame() so I don't see the reason why ignorenulls_getfuncarginframe() does not take account EXCLUSION frame options. (2) New member ignore_nulls are added to some structs. Its value is 0, 1 or -1. It's better to use a DEFINE for the value of ignore_nulls, rather than 0, 1, or -1. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp