Hi, On 2023-11-27 15:06:12 +0100, Alvaro Herrera wrote: > On 2023-Nov-27, Andrew Dunstan wrote: > > > Interesting. But inferring a speed effect from such changes is difficult. I > > don't have a good idea about measuring parser speed, but a tool to do that > > would be useful. Amit has made a start on such measurements, but it's only a > > start. I'd prefer to have evidence rather than speculation.
Yea, the parser table sizes are influenced by the increase in complexity of the grammar, but it's not a trivial correlation. Bison attempts to compress the state space and it looks like there are some heuristics involved. > At this point one thing that IMO we cannot afford to do, is stop feature > progress work on the name of parser speed. Agreed - I don't think anyone advocated that though. > 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?) Yea. Both perhaps. Being able to have sub-grammars would be quite powerful I think, and we might be able to do it without loosing cross-checking from bison that our grammar is conflict free. Even if the resulting combined state space is larger, better locality should more than make up for that. > The amount of effort spent on the parsing aspect on this thread seems in > line with what we should always be doing: keep an eye on it, but not > disregard the work just because the parser tables have grown. I think we've, in other threads, not paid enough attention to it and just added stuff to the grammar in the first way that didn't produce shift/reduce conflicts... Of course a decent part of the problem here is the SQL standard that so seems to like adding one-off forms of grammar (yes, func_expr_common_subexpr, I'm looking at you)... Greetings, Andres Freund