"Which Parsing Approach?" DuckDB's PEG parser post made me go down the rabbit hole and re-read on parsing for a bit. This is a nice overview on different approaches, by @ltratt.bsky.social. tratt.net/laurie/blog/... - ThreadSky

gunnarmorling.dev • 93 days ago

"Which Parsing Approach?"

DuckDB's PEG parser post made me go down the rabbit hole and re-read on parsing for a bit. This is a nice overview on different approaches, by @ltratt.bsky.social.

https://tratt.net/laurie/blog/2020/which_parsing_approach.html

Comments

ry.codes•92 days ago

Still a fan of parser combinators. One of the few reasons to use Scala for anything imo.

grumpy-catus.bsky.social•93 days ago

But but isn’t the sql parsing on every execution an outrageous waste of resources? I wish the parsing problem was naturally such hard that nobody would even consider this is a fine idea to parse every damned execution. It can be done better. It has been done better.

gunnarmorling.dev•93 days ago

This is where prepared statements come in (for OLTP)? For OLAP like DuckDB, one (or even a few) ms for parsing doesn't make a significant difference, I'd say.

grumpy-catus.bsky.social•93 days ago

Prepared is one way doing it. The db’es which names will not be mentioned actually implemented most of them. When CPU cycles were at the premium. OTOH if duckdb doesn’t care then why bother? But nature demonstrates that versatile products win. Sooner than later analytics db gets hit.

grumpy-catus.bsky.social•93 days ago

A typical scenario. Analytics db - no indexes, just semi-sorted tables(guess the name). A frequent dashboard query lands into it. Somebody will jump - we need ANOTHER db just for that simple query. Good luck.

carlopi.bsky.social•93 days ago

You can avoid that via prepared statements. I guess DuckDB could also add a cache of recently parsed statements, if this were to be significant I guess we will look into this.

grumpy-catus.bsky.social•93 days ago

The fastest parsing is parsing never done.
DuckDB may get away with it.
But hyperscalers warming Mother Earth in every execution is hilarious.

a13x.bsky.social•93 days ago

In MotherDuck, the parsing occurs client-side, so the cloud is free from that workload!

grumpy-catus.bsky.social•93 days ago

That’s one way. There is an interesting balance between storing parse results vs parsing every darned single time. If development is serious it is better have control over it

hexorer.bsky.social•93 days ago

1ms for parsing a SQL statement sounds way too much time in my opinion... I'd expect it to be much lower in commodity hardware. or even in mobile phones tbh.

gunnarmorling.dev•93 days ago

Sure, I just meant to give a conservative estimate for the sake of the argument. The point being that this doesn't really matter--from the perspective of a user submitting that query--if it then takes seconds to be run.

grumpy-catus.bsky.social•92 days ago

To clarify, is parsing understood in db sense - parsing plus optimizing, all the way down to the execution plan?
Or, in case of adaptive execution, some adaptive execution plan?

hexorer.bsky.social•92 days ago

I was talking about just parsing to AST or other (better) forms of representing the statements for planner and optimizer.

If things are noticeable, people would talk about it with actual scenarios and experiences.

I would save the effort if I were implementing the system. for these reasons: \

Comments

Posting Rules

Reply