From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Guyren Howe <guyren(at)gmail(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: nth_value out of more than n values returns null |
Date: | 2024-11-04 23:36:17 |
Message-ID: | 50219ea2-3431-403e-b651-8120162370f1@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/4/24 15:17, Guyren Howe wrote:
> This query:
>
> SELECT NTH_VALUE(id, 5000000) OVER (ORDER BY created_at, id ASC) FROM table
>
> in a table where SELECT COUNT(*) returns a value a few thousand over 5
> million, where id is the primary key, returns null.
>
> The inclusion of the primary key should make the order by a total order.
> So there should be a 5 millionth row.
>
> How can this happen?
If I where to hazard a guess it has to do with this:
https://www.postgresql.org/docs/current/functions-window.html
"Note that first_value, last_value, and nth_value consider only the rows
within the “window frame”, which by default contains the rows from the
start of the partition through the last peer of the current row. This is
likely to give unhelpful results for last_value and sometimes also
nth_value. You can redefine the frame by adding a suitable frame
specification (RANGE, ROWS or GROUPS) to the OVER clause. See Section
4.2.8 for more information about frame specifications."
Further I am pretty sure that this ORDER BY created_at, id ASC is
creating a window frame over created_at, id and that there are duplicate
created_at values which means the frame has less then 5000000 rows. Try
a smaller number and see what happens.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2024-11-04 23:36:24 | Re: nth_value out of more than n values returns null |
Previous Message | Guyren Howe | 2024-11-04 23:17:16 | nth_value out of more than n values returns null |