Fix performance of very nested SQL files, add example to benchmark

[Dandandan]

This adds one of the inputs found during fuzzing as benchmarking input.

#216

According to benchmark,the query takes 75.814 ms on average. That is much more than the other benchmarks, which are more than 1000x as fast (3 / 17 microseconds).

I included a fix which memoizes the unsuccesful usage of parse_derived_table_factor.

This brings down the benchmark to 109.24 microseconds (687 times speedup for this extreme example).

[coveralls]

Pull Request Test Coverage Report for Build 152428199

• 6 of 7 (85.71%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.01%) to 91.768%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser.rs	6	7	85.71%

Totals
Change from base Build 150634388:	-0.01%
Covered Lines:	4225
Relevant Lines:	4604

---

💛 - Coveralls

[Dandandan]

I included a fix which memoizes the unsuccesful usage of parse_derived_table_factor.

This brings down the benchmark to 109.24 microseconds (687 times speedup for this extreme example).

[alamb]

@Dandandan Is this PR still something we should work on to help contribute?

[Dandandan]

@Dandandan Is this PR still something we should work on to help contribute?

I think the benchmark is a useful example of some problematic input for the parser.
Not sure whether this PR is a good way to solve it (better would be to rewrite the parser to avoid this)

[alamb]

Closing old PRs. Please feel free to re-open if this was a mistake