public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v2 3/7] Row pattern recognition patch (planner).
4+ messages / 4 participants
[nested] [flat]
* [PATCH v2 3/7] Row pattern recognition patch (planner).
@ 2023-06-26 08:05 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Tatsuo Ishii @ 2023-06-26 08:05 UTC (permalink / raw)
---
src/backend/optimizer/plan/createplan.c | 19 ++++++++++++++-----
src/include/nodes/plannodes.h | 12 ++++++++++++
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index 4bb38160b3..c10ac65a4c 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -286,9 +286,9 @@ static WindowAgg *make_windowagg(List *tlist, Index winref,
int ordNumCols, AttrNumber *ordColIdx, Oid *ordOperators, Oid *ordCollations,
int frameOptions, Node *startOffset, Node *endOffset,
Oid startInRangeFunc, Oid endInRangeFunc,
- Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst,
- List *runCondition, List *qual, bool topWindow,
- Plan *lefttree);
+ Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, List *runCondition,
+ RPSkipTo rpSkipTo, List *patternVariable, List *patternRegexp, List *defineClause,
+ List *qual, bool topWindow, Plan *lefttree);
static Group *make_group(List *tlist, List *qual, int numGroupCols,
AttrNumber *grpColIdx, Oid *grpOperators, Oid *grpCollations,
Plan *lefttree);
@@ -2684,6 +2684,10 @@ create_windowagg_plan(PlannerInfo *root, WindowAggPath *best_path)
wc->inRangeAsc,
wc->inRangeNullsFirst,
wc->runCondition,
+ wc->rpSkipTo,
+ wc->patternVariable,
+ wc->patternRegexp,
+ wc->defineClause,
best_path->qual,
best_path->topwindow,
subplan);
@@ -6580,8 +6584,9 @@ make_windowagg(List *tlist, Index winref,
int ordNumCols, AttrNumber *ordColIdx, Oid *ordOperators, Oid *ordCollations,
int frameOptions, Node *startOffset, Node *endOffset,
Oid startInRangeFunc, Oid endInRangeFunc,
- Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst,
- List *runCondition, List *qual, bool topWindow, Plan *lefttree)
+ Oid inRangeColl, bool inRangeAsc, bool inRangeNullsFirst, List *runCondition,
+ RPSkipTo rpSkipTo, List *patternVariable, List *patternRegexp, List *defineClause,
+ List *qual, bool topWindow, Plan *lefttree)
{
WindowAgg *node = makeNode(WindowAgg);
Plan *plan = &node->plan;
@@ -6607,6 +6612,10 @@ make_windowagg(List *tlist, Index winref,
node->inRangeAsc = inRangeAsc;
node->inRangeNullsFirst = inRangeNullsFirst;
node->topWindow = topWindow;
+ node->rpSkipTo = rpSkipTo,
+ node->patternVariable = patternVariable;
+ node->patternRegexp = patternRegexp;
+ node->defineClause = defineClause;
plan->targetlist = tlist;
plan->lefttree = lefttree;
diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h
index 1b787fe031..cc942b9c12 100644
--- a/src/include/nodes/plannodes.h
+++ b/src/include/nodes/plannodes.h
@@ -1096,6 +1096,18 @@ typedef struct WindowAgg
/* nulls sort first for in_range tests? */
bool inRangeNullsFirst;
+ /* Row Pattern Recognition AFTER MACH SKIP clause */
+ RPSkipTo rpSkipTo; /* Row Pattern Skip To type */
+
+ /* Row Pattern Recognition PATTERN variable name (list of String) */
+ List *patternVariable;
+
+ /* Row Pattern Recognition PATTERN regular expression quantifier ('+' or ''. list of String) */
+ List *patternRegexp;
+
+ /* Row Pattern Recognition DEFINE clause (list of TargetEntry) */
+ List *defineClause;
+
/*
* false for all apart from the WindowAgg that's closest to the root of
* the plan
--
2.25.1
----Next_Part(Mon_Jun_26_17_45_07_2023_724)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v2-0004-Row-pattern-recognition-patch-executor.patch"
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Having problems generating a code coverage report
@ 2026-02-14 08:04 Stefan Kaltenbrunner <[email protected]>
2026-02-16 01:49 ` Re: Having problems generating a code coverage report Michael Paquier <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Kaltenbrunner @ 2026-02-14 08:04 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Aleksander Alekseev <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Geoghegan <[email protected]>
On 1/29/25 02:00, Michael Paquier wrote:
> On Wed, Jan 15, 2025 at 07:51:39PM -0500, Peter Geoghegan wrote:
>> I was able to get the lcov git master branch's tip to produce a
>> Postgres coverage report (same compiler version and OS as before).
>> Unfortunately, I had to use an even grottier incantation to get this
>> to work:
>>
>> make -s coverage-html GENHTML_FLAGS="-q --legend --ignore-errors
>> unmapped,unmapped,empty,empty,inconsistent,inconsistent,corrupt,corrupt,range,range"
>> LCOVFLAGS="--ignore-errors
>> empty,empty,negative,negative,inconsistent,inconsistent"
>>
>> (As you can imagine, I came up with this through pure trial and error.)
>
> Interesting. These tricks do not seem to work here with a Debian GID
> host, unfortunately. I'll try to dig a bit more, this is getting very
> annoying :(
hmm this is now also breaking coverage.postgresql.org (after an upgrade
to the current debian trixie):
make: Leaving directory
'/home/coverage/pgsrc/pgsql/src/interfaces/ecpg/test'
/usr/bin/lcov --gcov-tool /usr/bin/gcov -q --no-external -c -i -d . -d .
-o lcov_base.info
lcov: WARNING: (deprecated) RC option 'lcov_branch_coverage' is
deprecated. Consider using 'branch_coverage'. instead.
(Backward-compatible support will be removed in the future.)
(use "lcov --ignore-errors deprecated,deprecated ..." to
suppress this warning)
Message summary:
1 error message:
usage: 1
1 warning message:
deprecated: 1
lcov: ERROR: (usage) duplicate file ./src/fe_utils/astreamer_gzip.gcno
in both . and .
(use "lcov --ignore-errors usage ..." to bypass this error)
make: *** [src/Makefile.global:1064: lcov_base.info] Error 1
This seems to be basically the same issue that Andres patch in this
thread tries to address by removing one of the -d - applying a similar
hack locally seems to help a bit until we are running into one of the
other reported issues:
lcov: WARNING: (inconsistent)
/home/coverage/pgsrc/pgsql/contrib/bloom/blinsert.c:274: unexecuted
block on non-branch line with non-zero hit count. Use "geninfo --rc
geninfo_unexecuted_blocks=1 to set count to zero.
(use "lcov --ignore-errors inconsistent,inconsistent ..." to suppress
this warning)
lcov: ERROR: (negative) Unexpected negative hit count '-5' for line
/home/coverage/pgsrc/pgsql/src/port/snprintf.c:529" while capturing from
./src/port/snprintf_shlib.gcda.
(use "lcov --ignore-errors negative ..." to bypass this error)
Message summary:
1 error message:
negative: 1
2 warning messages:
deprecated: 1
inconsistent: 1
make: *** [src/Makefile.global:1069: lcov_test.info] Error 1
While I certainly can try to locally hack around that further to get it
build it feels wrong to post process/patch our own tree to get
"official" coverage reporting...
Stefan
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Having problems generating a code coverage report
2026-02-14 08:04 Re: Having problems generating a code coverage report Stefan Kaltenbrunner <[email protected]>
@ 2026-02-16 01:49 ` Michael Paquier <[email protected]>
2026-02-17 17:10 ` Re: Having problems generating a code coverage report Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Michael Paquier @ 2026-02-16 01:49 UTC (permalink / raw)
To: Stefan Kaltenbrunner <[email protected]>; +Cc: Tom Lane <[email protected]>; Aleksander Alekseev <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Geoghegan <[email protected]>
On Sat, Feb 14, 2026 at 09:04:44AM +0100, Stefan Kaltenbrunner wrote:
> While I certainly can try to locally hack around that further to get it
> build it feels wrong to post process/patch our own tree to get "official"
> coverage reporting...
Are you using a VPATH build? That was the only build option that was
causing me problems on Debian GID even with the tweaks proposed by
Andres in a .lcovrc. Non-vpath under configure and meson worked
unpatched. With vpath under configure, that worked but the
directories were in a weird state (contrib/ missing from the root
patch, $HOME included). meson was much slower than the two others.
I have also tried a few more experiments on Fedora 34 lately, that
points to even newer versions of all these tools. Things are even
more broken moving forward for meson, vpath and non-vpath. This is
testing things with an unpatched PG tree, just mentioning that it
does not seem to get better as time goes..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Having problems generating a code coverage report
2026-02-14 08:04 Re: Having problems generating a code coverage report Stefan Kaltenbrunner <[email protected]>
2026-02-16 01:49 ` Re: Having problems generating a code coverage report Michael Paquier <[email protected]>
@ 2026-02-17 17:10 ` Álvaro Herrera <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Álvaro Herrera @ 2026-02-17 17:10 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Stefan Kaltenbrunner <[email protected]>; Tom Lane <[email protected]>; Aleksander Alekseev <[email protected]>; PostgreSQL Hackers <[email protected]>; Peter Geoghegan <[email protected]>
On 2026-Feb-16, Michael Paquier wrote:
> On Sat, Feb 14, 2026 at 09:04:44AM +0100, Stefan Kaltenbrunner wrote:
> > While I certainly can try to locally hack around that further to get it
> > build it feels wrong to post process/patch our own tree to get "official"
> > coverage reporting...
>
> Are you using a VPATH build?
Nope, it's a straight in-tree build. I made it work after a few more
failed tries with a call like
GENHTML_FLAGS="-q --legend --ignore-errors unmapped,corrupt,inconsistent,range"
LCOVFLAGS="-q --legend --ignore-errors usage"
make coverage-html
... and we have a nice (??) trace of what errors are being ignored. I
think this is absolutely bonkers, but who knows when or if lcov and its
tools are going to be fixed in a way that allows our tree to be
processed correctly.
However, it appears that there are problems with the CSS, because the
lines are not colored anymore. I have no idea how to get this to work,
but you can see the result running lcov 2.0 in
https://coverage.postgresql.org/
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
https://postgr.es/m/[email protected]
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-02-17 17:10 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-26 08:05 [PATCH v2 3/7] Row pattern recognition patch (planner). Tatsuo Ishii <[email protected]>
2026-02-14 08:04 Re: Having problems generating a code coverage report Stefan Kaltenbrunner <[email protected]>
2026-02-16 01:49 ` Re: Having problems generating a code coverage report Michael Paquier <[email protected]>
2026-02-17 17:10 ` Re: Having problems generating a code coverage report Álvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox