Re: Row pattern recognition

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: assam258(at)gmail(dot)com
Cc: zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-03-21 14:16:29
Message-ID: 20260321.231629.266287379124559013.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Henson,

>> So, if RPR is active, WinSetMarkPosition() is not called at all? That
>> seems too strong limitation. Can't we set mark at frameheadpos even
>> if RPR is active? It seems safe since the only allowed franme start
>> option is ROWS BETWEEN CURRENT ROW and we never step back to the rows
>> before frameheadpos.
>
>
> You raise a valid point. Setting mark at frameheadpos would be safe
> for the window function's own read pointer, since we only allow
> ROWS BETWEEN CURRENT ROW.
>
> However, the difficulty is with the PREV/NEXT navigation. In the
> experimental patch, PREV accepts an optional offset argument --
> e.g. PREV(price, N) -- and this offset can be a runtime expression
> whose value is not known until evaluation time. If the mark is
> advanced to frameheadpos, PREV(price, N) with a large N could try
> to access rows that the tuplestore has already truncated.
>
> This is why the experimental patch takes a different approach: it
> creates a separate nav_winobj with its own mark pointer pinned at
> position 0, so that the tuplestore never truncates rows that PREV
> might need. The window function's own mark management is left
> unchanged.
>
> The mark=0 approach is safe but conservative -- it prevents the
> tuplestore from releasing any rows within the partition. The SQL
> standard (ISO/IEC 19075-5, Subclause 5.6.2) requires the offset
> argument to be a "runtime constant" -- meaning it cannot reference
> columns or row pattern variables. So in practice, the maximum
> offset is always known at plan time, which opens the door for a
> future optimization: advance the mark to (currentpos - max_offset)
> when all PREV offsets in the DEFINE clause are constant.
>
> Since the experimental patch redesigns how mark works for PREV/NEXT
> navigation, I think we should drop 0004 from the current series
> and revisit the set_mark question together with the experimental
> patch. What do you think?

Agreed. So I just want to make sure I create v46 using 0001-0003 and
0005-0015. Am I correct?

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-03-21 14:45:46 Re: pg_waldump: support decoding of WAL inside tarfile
Previous Message Dmitry Dolgov 2026-03-21 13:25:18 Re: Add ssl_(supported|shared)_groups to sslinfo