MIME-Version: 1.0
References: <f8a61d0b-0b85-ee42-0b6f-0d62b19d6e24@dunslane.net>
 <202311271406.budphctjy3p3@alvherre.pgsql>
In-Reply-To: <202311271406.budphctjy3p3@alvherre.pgsql>
From: John Naylor <johncnaylorls@gmail.com>
Date: Mon, 22 Jan 2024 13:19:17 +0700
Message-ID: 
 <CANWCAZZPQNnH8z_3z6Fs+2ton=1BWH-cOhhSbKfEXBoJ+Jq3_A@mail.gmail.com>
Subject: Re: remaining sql/json patches
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andrew Dunstan <andrew@dunslane.net>,
 Amit Langote <amitlangote09@gmail.com>,
	Andres Freund <andres@anarazel.de>, jian he <jian.universality@gmail.com>,
	Erik Rijkers <er@xs4all.nl>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZZPQNnH8z_3z6Fs%2B2ton%3D1BWH-cOhhSbKfEXBoJ%2BJq3_A%40mail.gmail.com>
Precedence: bulk

On Mon, Nov 27, 2023 at 9:06=E2=80=AFPM Alvaro Herrera <alvherre@alvh.no-ip=
.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.