Re: Row pattern recognition

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: assam258(at)gmail(dot)com
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, 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-10-28 03:16:07
Message-ID: CACJufxEi27WOUbYtN_tEuGYiwujo=dqinyvTpSme9JxOLOa=ag@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi.

I'd like to remove RPRElemCanExit() and RPRElemCanLoop() and compare
the count with min and max directly.

RPRElemIsVar() and RPRElemIsEnd() are fine, because their names say
exactly what they test.
"Can exit" and "Can loop" don't: to understand them, the reader has to
work out what they mean for the count,
while ``(count < elem->min)`` or ``(count >= elem->max)`` needs no explanation.

Similarly, I also want to remove RPRCountIncrement and RPRElemWithinMax.
---------------
I'm still not convinced by how EXPLAIN shows context absorption (I may have
asked about this before). See append_rpr_quantifier.
The pattern is printed with markers on its elements, "#" for the
comparison point and "~" for the elements inside the absorbable
region,
for example:

Pattern: (((a~ b~)+# c)+ d)+

This seems odd to me, because the pattern as the user wrote it no longer
appears anywhere in the plan. The markers are compact, but they are hard to
read for anyone who does not already know the absorption design, and since
they change the pattern text itself, every EXPLAIN output that shows a
pattern carries them.

A single extra line could say the same thing:

Pattern: (((a b)+ c)+ d)+
Absorbable Pattern: (a b)+

and for a pattern that cannot be absorbed, the line would simply be absent:

Pattern: s a+ b

Is there a reason the markers are preferable?

--
jian
https://www.enterprisedb.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Roman Khapov 2026-10-28 05:04:00 Re: Print pgbench results on SIGINT
Previous Message David Rowley 2026-10-28 03:13:37 Re: Any reason to keep HEAP_HASOID_OLD?