Tom Lane wrote:
As best I can tell after some casual testing on a couple of machines,
the actual bottom line is that "raw_parser" (ie, the bison and flex
processing) is going to be a couple of percent slower with a reentrant
grammar and lexer, for typical queries involving a lot of short tokens.
Now this disappears into the noise as soon as you include parse analysis
(let alone planning and execution), but it is possible to measure the
slowdown in a test harness that calls raw_parser only.
A possible compromise that I think would avoid most or all of the
slowdown is to make the lexer reentrant but not the grammar (so that
yylval and yylloc remain as global variables instead of being parameters
to yylex). I haven't actually benchmarked that, though. It strikes
me as a fairly silly thing to do. If we're going to go for reentrancy
I think we should fix both components.
I'm willing to live with the small slowdown. Comments?
If we're going to have a reentrant lexer, I think we should go the whole
nine yards. I agree that a couple of percent slowdown on just the lexing
and parsing will be lost in the noise. So +1 from me.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
