MIME-Version: 1.0
References: 
 <CAAAe_zDmjV-R6M0xeMDzZN+eRVUhsrt6NA=xjvj9BQMog9tqTQ@mail.gmail.com>
 <20260321.231629.266287379124559013.ishii@postgresql.org>
 <CAAAe_zDneX+WWEgoM+rXLg+H2OK_VuXoiipzJu2Q0rCSSCzY8g@mail.gmail.com>
 <20260322.142326.546998002680149319.ishii@postgresql.org>
 <CAAAe_zBCF3dwSjStmG0kJqw_y1z8QD73Rf1G58QTKEvd9tScwA@mail.gmail.com>
In-Reply-To: 
 <CAAAe_zBCF3dwSjStmG0kJqw_y1z8QD73Rf1G58QTKEvd9tScwA@mail.gmail.com>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Sun, 29 Mar 2026 23:06:11 +0900
Message-ID: 
 <CAAAe_zCUrKGBgZdaazdO_v9QWHsS_1DXuP=rLeNhO3iwsHwwbg@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: zsolt.parragi@percona.com, sjjang112233@gmail.com,
 vik@postgresfriends.org,
	er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
	peter@eisentraut.org, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000003435c3064e2a3d30"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zCUrKGBgZdaazdO_v9QWHsS_1DXuP%3DrLeNhO3iwsHwwbg%40mail.gmail.com>
Precedence: bulk

--0000000000003435c3064e2a3d30
Content-Type: text/plain; charset="UTF-8"

Hi Tatsuo,

Separately from the PREV/NEXT patches, I have been analyzing
how FIRST and LAST navigation would interact with the current
NFA engine -- particularly context absorption and DEFINE
evaluation sharing. This is not a proposal to implement them
now; rather, I wanted to document the design constraints
while the analysis is fresh, so we have a reference when we
are ready to add them.


Design Note: FIRST/LAST Navigation for RPR
===========================================

Scope: This note covers only patterns without quantifiers, where
each pattern variable consumes exactly one row.


1. Navigation Function Classification
--------------------------------------

The SQL standard (ISO/IEC 19075-5:2021) defines four navigation
functions in two categories:

PREV/NEXT -- physical navigation:
  - Scope: entire row pattern partition
  - Offset: physical (row position within partition)
  - Base row: the row denoted by the variable under running
    semantics (in our no-qualifier scope: current eval row)
  - Default offset: 1
  - Can reach rows outside the match (standard 5.6.2)
  - Always RUNNING semantics only

FIRST/LAST -- logical navigation:
  - Standard scope: rows mapped to a specific variable
  - Our scope (no quantifier): match_start to currentpos range
  - Offset: logical (in standard), but equivalent to physical
    when each variable maps to at most one row
  - Base: match_start (FIRST) or currentpos (LAST)
  - Default offset: 0 (unlike PREV/NEXT which default to 1)
  - RUNNING semantics in DEFINE; FINAL available in MEASURES

FIRST/LAST results depend on the match start position
(match_start). Each current row in window RPR triggers an
independent match attempt with its own match_start. FIRST
always depends on match_start. LAST(price) depends only on
currentpos and is match_start-independent, but LAST(price, N)
depends on match_start because the NULL boundary check
(currentpos - N < match_start) varies with match_start.

Example (PATTERN (A B C), match_start = 3):

    FIRST(price)    = R3.price   (match_start row)
    FIRST(price, 1) = R4.price   (match_start + 1)
    LAST(price)     = R5.price   (currentpos row)
    LAST(price, 1)  = R4.price   (currentpos - 1)
    LAST(price, 3)  = NULL       (before match_start)

    PREV(price, 2)  = R3.price   (pos - 2, physical)
    NEXT(price, 2)  = R7.price   (pos + 2, beyond match)

PREV/NEXT can reach any row in the partition regardless of
match boundaries. FIRST/LAST are valid only within the
match_start to currentpos range.


2. match_start and NFA Contexts
-------------------------------

Each match_start defines one match attempt, which corresponds
to one NFA context. Different contexts have different
match_start values. Context absorption merges contexts when
one context's pattern states are covered by another's. If the
merged contexts have different match_start values, FIRST/LAST
would produce incorrect results because the surviving context's
match_start would be used for both.


3. Compound Navigation (PREV/NEXT wrapping FIRST/LAST)
------------------------------------------------------

The standard (5.6.4) permits nesting FIRST/LAST inside
PREV/NEXT. Using the standard's notation with variable
qualifiers (which our no-quantifier scope does not yet
require):

    PREV(LAST(A.Price + A.Tax, 1), 3)

Evaluation proceeds in three steps:
  1. Inner FIRST/LAST: determines target row position only
     (does not evaluate the expression)
  2. Outer PREV/NEXT: applies physical offset from that row
  3. Expression evaluation: at the final destination row only

The reverse nesting (FIRST/LAST wrapping PREV/NEXT) and
same-kind nesting (PREV inside PREV, etc.) are prohibited.

Since the inner function only determines a position, the
compound operation can be flattened into a single RPRNavExpr
node internally, requiring only one slot swap.


4. Context Absorption Rules
----------------------------

Absorption safety depends on whether the navigation function
depends on match_start:

  DEFINE content                  | match_start dep. | absorption
  --------------------------------|------------------|----------
  No navigation                   | none             | safe
  PREV/NEXT only                  | none             | safe
  LAST (no offset)                | none             | safe
  LAST (with offset)              | boundary check   | unsafe
  FIRST (any)                     | direct           | unsafe
  Compound (inner FIRST)          | direct           | unsafe
  Compound (inner LAST, no off.)  | none             | safe
  Compound (inner LAST, with off.)| boundary check   | unsafe

The criterion: if the expression depends on match_start in
any way, absorption is unsafe. Comparing match_start values
at runtime is impractical, so we treat any dependency as
unconditionally unsafe.


5. DEFINE Clause Evaluation Rules
---------------------------------

Currently, nfa_evaluate_row(pos) evaluates all DEFINE
variables once per row and shares the results across all NFA
contexts.

  DEFINE content                  | evaluation
  --------------------------------|--------------------------
  No navigation                   | shared (once per row)
  PREV/NEXT only                  | shared (once per row)
  LAST (no offset)                | shared (once per row)
  LAST (with offset)              | per-context
  FIRST (any)                     | per-context
  Compound (inner FIRST)          | per-context
  Compound (inner LAST, no off.)  | shared (once per row)
  Compound (inner LAST, with off.)| per-context


6. Slot Swap Elision
--------------------

When the final target position resolves to currentpos, the
slot swap can be elided. This applies to:
  - PREV(price, 0), NEXT(price, 0): offset 0
  - LAST(price), LAST(price, 0): always currentpos
  - Compound cases where offsets cancel, e.g.,
    NEXT(LAST(price, 1), 1)


The PREV/NEXT infrastructure (RPRNavExpr, EEOP_RPR_NAV_SET/
RESTORE, nav_winobj) can be reused directly for FIRST/LAST --
it would mainly require adding two RPRNavKind values and
match_start arithmetic in the ExecEvalRPRNavSet switch.
No variable qualifiers, match history tracking, or CLASSIFIER
infrastructure would be needed for this no-quantifier scope.

I do think CLASSIFIER, MEASURES, and match history tracking
should stay out of the initial patch set -- they add
significant complexity to NFA contexts and affect absorption
in ways that are hard to validate incrementally. Variable
qualifiers and quantifier support for navigation functions
are also tied to match history infrastructure, so they should
be deferred as well. Better to get the current feature set
stable first.

With PREV/NEXT now resolved (0006), the next major milestone
would be match history infrastructure (needed for CLASSIFIER,
MEASURES, variable qualifiers, and quantifier-aware
navigation). Before that larger step, there are a few
remaining items that can be done within the current
architecture:

Optimization:
  - PREFIX pattern absorption (e.g., A (B+) C) [1][2]
  - Fixed-length iteration group absorption
    (e.g., (A B{2})+ ) [3]

Feature:
  - FIRST/LAST navigation (this note)
  - LLVM JIT proper support for slot swap (0006 uses
    interpreter fallback) [4][5]

[1]
https://www.postgresql.org/message-id/CAAAe_zAEg7sVM%3DWDwXMyE-odGmQyXSVi5ZzWgye6SupSjdMKpg%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAAAe_zDq7R8CaDfmh8C%2BH3_639Y5LtJD%2B2Z%3D1txDt%3DvaOr90rQ%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/CAAAe_zBY%2BEqk_DQpS0cy1Eb67H9v92tyaf%2BU%2BSKKuLGUs_z%2BEA%40mail.gmail.com
[4]
https://www.postgresql.org/message-id/CAAAe_zBbrnx2fjK2s%2BJgx6TSOdnKAPawXbHeX49WqmX9ji%2BHdg%40mail.gmail.com
[5]
https://www.postgresql.org/message-id/CAAAe_zBCF3dwSjStmG0kJqw_y1z8QD73Rf1G58QTKEvd9tScwA%40mail.gmail.com

The question is how much of this to complete before the
current patches are committed. The patch set is already
substantial, and the next CommitFest is in July. What do
you think -- should we try to include some of these items
in the current round, or focus on getting what we have
committed first? Also, do you see any blockers that might
prevent the current patch set from being committed?


Best regards,
Henson

>

--0000000000003435c3064e2a3d30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tatsuo,<br><br>Separately from the PRE=
V/NEXT patches, I have been analyzing<br>how FIRST and LAST navigation woul=
d interact with the current<br>NFA engine -- particularly context absorptio=
n and DEFINE<br>evaluation sharing. This is not a proposal to implement the=
m<br>now; rather, I wanted to document the design constraints<br>while the =
analysis is fresh, so we have a reference when we<br>are ready to add them.=
<br><br><br>Design Note: FIRST/LAST Navigation for RPR<br>=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><br>Scope: This note covers only=
 patterns without quantifiers, where<br>each pattern variable consumes exac=
tly one row.<br><br><br>1. Navigation Function Classification<br>----------=
----------------------------<br><br>The SQL standard (ISO/IEC 19075-5:2021)=
 defines four navigation<br>functions in two categories:<br><br>PREV/NEXT -=
- physical navigation:<br>=C2=A0 - Scope: entire row pattern partition<br>=
=C2=A0 - Offset: physical (row position within partition)<br>=C2=A0 - Base =
row: the row denoted by the variable under running<br>=C2=A0 =C2=A0 semanti=
cs (in our no-qualifier scope: current eval row)<br>=C2=A0 - Default offset=
: 1<br>=C2=A0 - Can reach rows outside the match (standard 5.6.2)<br>=C2=A0=
 - Always RUNNING semantics only<br><br>FIRST/LAST -- logical navigation:<b=
r>=C2=A0 - Standard scope: rows mapped to a specific variable<br>=C2=A0 - O=
ur scope (no quantifier): match_start to currentpos range<br>=C2=A0 - Offse=
t: logical (in standard), but equivalent to physical<br>=C2=A0 =C2=A0 when =
each variable maps to at most one row<br>=C2=A0 - Base: match_start (FIRST)=
 or currentpos (LAST)<br>=C2=A0 - Default offset: 0 (unlike PREV/NEXT which=
 default to 1)<br>=C2=A0 - RUNNING semantics in DEFINE; FINAL available in =
MEASURES<br><br>FIRST/LAST results depend on the match start position<br>(m=
atch_start). Each current row in window RPR triggers an<br>independent matc=
h attempt with its own match_start. FIRST<br>always depends on match_start.=
 LAST(price) depends only on<br>currentpos and is match_start-independent, =
but LAST(price, N)<br>depends on match_start because the NULL boundary chec=
k<br>(currentpos - N &lt; match_start) varies with match_start.<br><br>Exam=
ple (PATTERN (A B C), match_start =3D 3):<br><br><font face=3D"monospace">=
=C2=A0 =C2=A0 FIRST(price) =C2=A0 =C2=A0=3D R3.price =C2=A0 (match_start ro=
w)<br>=C2=A0 =C2=A0 FIRST(price, 1) =3D R4.price =C2=A0 (match_start + 1)<b=
r>=C2=A0 =C2=A0 LAST(price) =C2=A0 =C2=A0 =3D R5.price =C2=A0 (currentpos r=
ow)<br>=C2=A0 =C2=A0 LAST(price, 1) =C2=A0=3D R4.price =C2=A0 (currentpos -=
 1)<br>=C2=A0 =C2=A0 LAST(price, 3) =C2=A0=3D NULL =C2=A0 =C2=A0 =C2=A0 (be=
fore match_start)<br><br>=C2=A0 =C2=A0 PREV(price, 2) =C2=A0=3D R3.price =
=C2=A0 (pos - 2, physical)<br>=C2=A0 =C2=A0 NEXT(price, 2) =C2=A0=3D R7.pri=
ce =C2=A0 (pos + 2, beyond match)</font><br><br>PREV/NEXT can reach any row=
 in the partition regardless of<br>match boundaries. FIRST/LAST are valid o=
nly within the<br>match_start to currentpos range.<br><br><br>2. match_star=
t and NFA Contexts<br>-------------------------------<br><br>Each match_sta=
rt defines one match attempt, which corresponds<br>to one NFA context. Diff=
erent contexts have different<br>match_start values. Context absorption mer=
ges contexts when<br>one context&#39;s pattern states are covered by anothe=
r&#39;s. If the<br>merged contexts have different match_start values, FIRST=
/LAST<br>would produce incorrect results because the surviving context&#39;=
s<br>match_start would be used for both.<br><br><br>3. Compound Navigation =
(PREV/NEXT wrapping FIRST/LAST)<br>----------------------------------------=
--------------<br><br>The standard (5.6.4) permits nesting FIRST/LAST insid=
e<br>PREV/NEXT. Using the standard&#39;s notation with variable<br>qualifie=
rs (which our no-quantifier scope does not yet<br>require):<br><br>=C2=A0 =
=C2=A0 PREV(LAST(A.Price + A.Tax, 1), 3)<br><br>Evaluation proceeds in thre=
e steps:<br>=C2=A0 1. Inner FIRST/LAST: determines target row position only=
<br>=C2=A0 =C2=A0 =C2=A0(does not evaluate the expression)<br>=C2=A0 2. Out=
er PREV/NEXT: applies physical offset from that row<br>=C2=A0 3. Expression=
 evaluation: at the final destination row only<br><br>The reverse nesting (=
FIRST/LAST wrapping PREV/NEXT) and<br>same-kind nesting (PREV inside PREV, =
etc.) are prohibited.<br><br>Since the inner function only determines a pos=
ition, the<br>compound operation can be flattened into a single RPRNavExpr<=
br>node internally, requiring only one slot swap.<br><br><br>4. Context Abs=
orption Rules<br>----------------------------<br><br>Absorption safety depe=
nds on whether the navigation function<br>depends on match_start:<br><br><f=
ont face=3D"monospace">=C2=A0 DEFINE content =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| match_start dep. | absorption<br>=C2=A0=
 --------------------------------|------------------|----------<br>=C2=A0 N=
o navigation =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 | none =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | safe<br>=C2=A0 PREV/NEX=
T only =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| none=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | safe<br>=C2=A0 LAST (no offset=
) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| none =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | safe<br>=C2=A0 LAST (with offset) =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| boundary check =C2=A0 | unsafe<b=
r>=C2=A0 FIRST (any) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 | direct =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | unsafe<br>=
=C2=A0 Compound (inner FIRST) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| direct =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | unsafe<br>=C2=A0 Compound (inner LAST,=
 no off.) =C2=A0| none =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | safe<br>=
=C2=A0 Compound (inner LAST, with off.)| boundary check =C2=A0 | unsafe<br>=
</font><br>The criterion: if the expression depends on match_start in<br>an=
y way, absorption is unsafe. Comparing match_start values<br>at runtime is =
impractical, so we treat any dependency as<br>unconditionally unsafe.<br><b=
r><br>5. DEFINE Clause Evaluation Rules<br>--------------------------------=
-<br><br>Currently, nfa_evaluate_row(pos) evaluates all DEFINE<br>variables=
 once per row and shares the results across all NFA<br>contexts.<br><br><fo=
nt face=3D"monospace">=C2=A0 DEFINE content =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| evaluation<br>=C2=A0 ---------------------=
-----------|--------------------------<br>=C2=A0 No navigation =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | shared (once per row=
)<br>=C2=A0 PREV/NEXT only =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0| shared (once per row)<br>=C2=A0 LAST (no offset) =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| shared (once per row)<br>=C2=
=A0 LAST (with offset) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| pe=
r-context<br>=C2=A0 FIRST (any) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | per-context<br>=C2=A0 Compound (inner FIRST) =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| per-context<br>=C2=A0 Compound (inner L=
AST, no off.) =C2=A0| shared (once per row)<br>=C2=A0 Compound (inner LAST,=
 with off.)| per-context<br></font><br><br>6. Slot Swap Elision<br>--------=
------------<br><br>When the final target position resolves to currentpos, =
the<br>slot swap can be elided. This applies to:<br>=C2=A0 - PREV(price, 0)=
, NEXT(price, 0): offset 0<br>=C2=A0 - LAST(price), LAST(price, 0): always =
currentpos<br>=C2=A0 - Compound cases where offsets cancel, e.g.,<br>=C2=A0=
 =C2=A0 NEXT(LAST(price, 1), 1)<br><br><br>The PREV/NEXT infrastructure (RP=
RNavExpr, EEOP_RPR_NAV_SET/<br>RESTORE, nav_winobj) can be reused directly =
for FIRST/LAST --<br>it would mainly require adding two RPRNavKind values a=
nd<br>match_start arithmetic in the ExecEvalRPRNavSet switch.<br>No variabl=
e qualifiers, match history tracking, or CLASSIFIER<br>infrastructure would=
 be needed for this no-quantifier scope.<br><br>I do think CLASSIFIER, MEAS=
URES, and match history tracking<br>should stay out of the initial patch se=
t -- they add<br>significant complexity to NFA contexts and affect absorpti=
on<br>in ways that are hard to validate incrementally. Variable<br>qualifie=
rs and quantifier support for navigation functions<br>are also tied to matc=
h history infrastructure, so they should<br>be deferred as well. Better to =
get the current feature set<br>stable first.<br><br>With PREV/NEXT now reso=
lved (0006), the next major milestone<br>would be match history infrastruct=
ure (needed for CLASSIFIER,<br>MEASURES, variable qualifiers, and quantifie=
r-aware<br>navigation). Before that larger step, there are a few<br>remaini=
ng items that can be done within the current<br>architecture:<br><br>Optimi=
zation:<br>=C2=A0 - PREFIX pattern absorption (e.g., A (B+) C) [1][2]<br>=
=C2=A0 - Fixed-length iteration group absorption<br>=C2=A0 =C2=A0 (e.g., (A=
 B{2})+ ) [3]<br><br>Feature:<br>=C2=A0 - FIRST/LAST navigation (this note)=
<br>=C2=A0 - LLVM JIT proper support for slot swap (0006 uses<br>=C2=A0 =C2=
=A0 interpreter fallback) [4][5]<br><br>[1] <a href=3D"https://www.postgres=
ql.org/message-id/CAAAe_zAEg7sVM%3DWDwXMyE-odGmQyXSVi5ZzWgye6SupSjdMKpg%40m=
ail.gmail.com">https://www.postgresql.org/message-id/CAAAe_zAEg7sVM%3DWDwXM=
yE-odGmQyXSVi5ZzWgye6SupSjdMKpg%40mail.gmail.com</a><br>[2] <a href=3D"http=
s://www.postgresql.org/message-id/CAAAe_zDq7R8CaDfmh8C%2BH3_639Y5LtJD%2B2Z%=
3D1txDt%3DvaOr90rQ%40mail.gmail.com">https://www.postgresql.org/message-id/=
CAAAe_zDq7R8CaDfmh8C%2BH3_639Y5LtJD%2B2Z%3D1txDt%3DvaOr90rQ%40mail.gmail.co=
m</a><br>[3] <a href=3D"https://www.postgresql.org/message-id/CAAAe_zBY%2BE=
qk_DQpS0cy1Eb67H9v92tyaf%2BU%2BSKKuLGUs_z%2BEA%40mail.gmail.com">https://ww=
w.postgresql.org/message-id/CAAAe_zBY%2BEqk_DQpS0cy1Eb67H9v92tyaf%2BU%2BSKK=
uLGUs_z%2BEA%40mail.gmail.com</a><br>[4] <a href=3D"https://www.postgresql.=
org/message-id/CAAAe_zBbrnx2fjK2s%2BJgx6TSOdnKAPawXbHeX49WqmX9ji%2BHdg%40ma=
il.gmail.com">https://www.postgresql.org/message-id/CAAAe_zBbrnx2fjK2s%2BJg=
x6TSOdnKAPawXbHeX49WqmX9ji%2BHdg%40mail.gmail.com</a><br>[5] <a href=3D"htt=
ps://www.postgresql.org/message-id/CAAAe_zBCF3dwSjStmG0kJqw_y1z8QD73Rf1G58Q=
TKEvd9tScwA%40mail.gmail.com">https://www.postgresql.org/message-id/CAAAe_z=
BCF3dwSjStmG0kJqw_y1z8QD73Rf1G58QTKEvd9tScwA%40mail.gmail.com</a><br><br>Th=
e question is how much of this to complete before the<br>current patches ar=
e committed. The patch set is already<br>substantial, and the next CommitFe=
st is in July. What do<br>you think -- should we try to include some of the=
se items<br>in the current round, or focus on getting what we have<br>commi=
tted first? Also, do you see any blockers that might<br>prevent the current=
 patch set from being committed?<br><br><br>Best regards,<br>Henson<br></di=
v><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
</blockquote></div></div>

--0000000000003435c3064e2a3d30--