On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@mit.edu> writes: >> But I'm not entirely convinced any of this is actually useful. Just >> becuase the transition table is large doesn't mean it's inefficient. > > That's a fair point. However, I've often noticed base_yyparse() showing > up rather high on profiles --- higher than seemed plausible at the time, > given that its state-machine implementation is pretty tight. Now I'm > wondering whether that isn't coming from cache stalls from trying to > touch all the requisite parts of the transition table.
For what it's worth the bloat isn't in the parser transition table at all: 516280 yy_transition 147208 yytable 147208 yycheck 146975 base_yyparse 17468 yypact 9571 core_yylex 8734 yystos 8734 yydefact Unless I'm confused yy_transition is in fact the *lexer* transition table. I'm not sure how to reconcile that with the profiling results showing the cache misses in base_yyparse() though. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
