From: | Jacob Champion <champion(dot)p(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
Cc: | er(at)xs4all(dot)nl, vik(at)postgresfriends(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Row pattern recognition |
Date: | 2023-10-30 19:49:18 |
Message-ID: | CAGu=u8gr-DREbxJJc+UKwYz2t7nmecr+FeYSaqMk8vqFqQmbpg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 24, 2023 at 7:49 PM Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote:
> I am impressed the simple NFA implementation.
Thanks!
> It would be nicer if it
> could be implemented without using recursion.
Yeah. If for some reason we end up going with a bespoke
implementation, I assume we'd just convert the algorithm to an
iterative one and optimize it heavily. But I didn't want to do that
too early, since it'd probably make it harder to add new features...
and anyway my goal is still to try to reuse src/backend/regex
eventually.
> > SELECT aid, first_value(aid) OVER w,
> > count(*) OVER w
> > FROM pgbench_accounts
> > WINDOW w AS (
> > PARTITION BY bid
> > ORDER BY aid
> > ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING
> > AFTER MATCH SKIP PAST LAST ROW
> > INITIAL
> > PATTERN (START UP+)
> > DEFINE
> > START AS TRUE,
> > UP AS aid > PREV(aid)
> > );
>
> I ran this against your patch. It failed around > 60k rows.
Nice, that's actually more frames than I expected. Looks like I have
similar results here with my second test query (segfault at ~58k
rows).
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-10-30 19:51:09 | Re: Some performance degradation in REL_16 vs REL_15 |
Previous Message | Andres Freund | 2023-10-30 19:47:41 | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |