Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options

Oliver Ford <ojford@gmail.com>

From: Oliver Ford <ojford@gmail.com>

To: Tatsuo Ishii <ishii@postgresql.org>

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-17T16:43:29Z

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

0003-ignore-nulls.patch (application/octet-stream) patch 0003

On Thu, Sep 12, 2024 at 2:41 AM Tatsuo Ishii <ishii@postgresql.org> wrote:
>
> 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?

> 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.

> 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.