Re: Row pattern recognition

From: Henson Choi <assam258(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>, jian(dot)universality(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, li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-06-18 10:43:51
Message-ID: CAAAe_zCMZKTPq74Uhq-JSdNE9kAbhtA3NSXPOcwr0W31KFeVdw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tatsuo,

Thanks -- I'll go in this direction; your sketch has the shape of it.

> Yes, I think the direction is correct. Probably the patch would someting
> like this?
>
> + update_reduced_frame(winstate->nav_winobj,
> + winstate->frameheadpos);

Right: drive the match once per row, up front, instead of letting frame
access drive it. That's the plan, with two refinements on top of the
sketch.

First, a small refactor: I'll pull the reduced-frame loop and the mark
advance out into their own functions, called once per row before the window
functions run -- so the match tracks the row scan rather than frame reads.

Second, the mark: I'll advance it per NFA row from the match frontier rather
than the output row, so the tuplestore is trimmed as soon as the match is
done with each row.

Thanks,
Henson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-06-18 11:24:29 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Etsuro Fujita 2026-06-18 10:42:56 Re: use of SPI by postgresImportForeignStatistics