From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Amit Langote <amitlangote09(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, jian he <jian(dot)universality(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: remaining sql/json patches |
Date: | 2024-01-22 06:19:17 |
Message-ID: | CANWCAZZPQNnH8z_3z6Fs+2ton=1BWH-cOhhSbKfEXBoJ+Jq3_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 27, 2023 at 9:06 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> At this point one thing that IMO we cannot afford to do, is stop feature
> progress work on the name of parser speed. I mean, parser speed is
> important, and we need to be mindful that what we add is reasonable.
> But at some point we'll probably have to fix that by parsing
> differently (a top-down parser, perhaps? Split the parser in smaller
> pieces that each deal with subsets of the whole thing?)
I was reorganizing some old backups and rediscovered an experiment I
did four years ago when I had some extra time on my hands, to use a
lexer generator that emits a state machine driven by code, rather than
a table. It made parsing 12% faster on the above info-schema test, but
only (maybe) 3% on parsing pgbench-like queries. My quick hack ended
up a bit uglier and more verbose than Flex, but that could be
improved, and in fact small components could be shared across the
whole code base. I might work on it again; I might not.
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2024-01-22 06:22:11 | Re: Row pattern recognition |
Previous Message | Peter Smith | 2024-01-22 06:17:21 | Re: Moving forward with TDE [PATCH v3] |