Tim

Yeah, there doesn't seem to be redundant code here, nor particularly complex rules, but still a very large parser is generated. With compared to the `tree-sitter-python` parser, the size of...

> There is related issue in [tree-sitter/tree-sitter#1041](https://github.com/tree-sitter/tree-sitter/issues/1041) While removing parser from the repo is a good stop-gap solution, we would need to investigate the cause, generation times also getting progressively...

> > Yeah, there doesn't seem to be redundant code here, nor particularly complex rules, but still a very large parser is generated. > > With compared to the `tree-sitter-python`...

@m-novikov This PR is depend on PR#41, please merge PR#41 first

Thanks for your time @m-novikov , I will do it tomorrow

> This mostly question of my personal time :) I'll plan to review and merge your PRs by the end of this week. As I don't have too much time...

Hi @m-novikov I just rebased #40, #41 and #43 , please help review again at your convenient, thanks!

When I checked the `parser.c` file, I found the following paragraph repeated many times: ~~~ [*] = { [sym_within_group_clause] = STATE(93), [sym_filter_clause] = STATE(208), [sym_over_clause] = STATE(463), [sym_with_ordinality] = STATE(18),...

Updates: By counting the symbols in `parser.c`, there is a conspicuous characteristic found in `tree-sitter-sql`, i.e. There are many symbols prefixed with 'aux_' in the `parser.c` file. |Repo|Total lines|Prefixed lines|Prefixed/Total|...

Discussion with @yangbobo2021 This issue is not only related to the IntelliJ plugin, but may be a new workflow to be developed. The function of this workflow is to obtain...