Re: Row pattern recognition

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Row pattern recognition
Дата
Msg-id CAGu=u8gr-DREbxJJc+UKwYz2t7nmecr+FeYSaqMk8vqFqQmbpg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Row pattern recognition  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Ответы Re: Row pattern recognition  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список pgsql-hackers
On Tue, Oct 24, 2023 at 7:49 PM Tatsuo Ishii <ishii@sraoss.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Some performance degradation in REL_16 vs REL_15