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