Re: Row pattern recognition
| От | Henson Choi |
|---|---|
| Тема | Re: Row pattern recognition |
| Дата | |
| Msg-id | CAAAe_zCjtYWV9DnU95wv4Lu8hk_PQ3kg615c0ZbN8iDOsMBLSg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Row pattern recognition (Tatsuo Ishii <ishii@postgresql.org>) |
| Ответы |
Re: Row pattern recognition
|
| Список | pgsql-hackers |
Hi Ishii-san,
Thank you for the questions and corrections!
Thank you for the questions and corrections!
> 3. Proper Lexical Order support
> - Respects PATTERN alternative order for ONE ROW PER MATCH
RPR in WINDOW clause does not allow to specify "ONE ROW PER MATCH".
(nor ALL ROWS PER MATCH). So I am not sure what you mean here.
You're absolutely right to point this out. I've been working without access
to the SQL:2016 standard, relying on Oracle manuals and your implementation,
which led me to incorrectly treat Window clause RPR as a variant of
MATCH_RECOGNIZE.
to the SQL:2016 standard, relying on Oracle manuals and your implementation,
which led me to incorrectly treat Window clause RPR as a variant of
MATCH_RECOGNIZE.
I now realize there are fundamental differences between R010 (RPR in window
functions) and R020 (MATCH_RECOGNIZE), and I was conflating the two. My
company is supportive of this work, and we're planning to purchase the
standard next week so I can properly understand the spec requirements.
Thank you for catching this - it's exactly the kind of spec guidance I need
as I continue learning.
> 5. Incremental MEASURES computation
> - Aggregate values computed during matching, no rescan needed
In my understanding MEASURES does not directly connect to Aggregate
computation with rescan. Can you elaborate why implementing MEASURES
allows to avoid recan for aggregate computation?
Let me clarify what I meant by "incremental aggregation" and "rescan":
In the NFA design, I'm building infrastructure for incremental aggregatecomputation during pattern matching - maintaining SUM, COUNT, etc. as the
match progresses. When a match completes, if only aggregate functions are
needed, the result can be produced without accessing the original rows again.
I used "rescan" to contrast this with what I assumed was the existing
approach: match first, then aggregate over the matched row range afterward.
However, I haven't studied your implementation carefully enough to know if
this assumption is correct.
Could you clarify how aggregates are currently computed after pattern matching
in your implementation? This would help me understand whether the incremental
approach actually provides a benefit, or if I'm solving a problem that doesn't
exist.
Regarding MEASURES - I incorrectly connected it to this aggregation discussion.
As you noted, MEASURES is a separate R020 feature, not part of R010. The
incremental aggregation infrastructure would support both cases, but they're
distinct features.
Best regards,
Henson
В списке pgsql-hackers по дате отправления: