This would be incredible to understand why some queries execute slow; most of the time it's one of the steps in between that takes 99% of the execution time at our company. Do you record the time each step takes?
replyThis is awesome! I’m work with a team of analysts and data engineers who own a pretty big snowflake data warehouse. We write a ton of dbt models and have a range of sql skill levels on the team. This would be the perfect way to allow more junior devs to build their skills quickly and support more complex models.
replyI would recommend you target data warehouses like snowflake and bigquery where the query complexity and thus value prop for a tool like this is potentially much higher.
Thank you, nice to get some idea validation from folks in the industry. For sure data warehouses are the top priority on my TODO list, I picked PG first because that's what I'm familiar with.
replyI can ping you via email when the debugger is ready, if you're interested. My email is in my profile
Was thinking today... not a debugger but even a SQL progess bar, so I know that my add column will take say 7 hours in advance.
replyCool! We're dealing with many complex CTEs and costly queries. Would be useful to have those visualized one by one.
replyNice one!
replyThis seems like it could be extremely useful.
replyThanks! Would you mind sharing what would be your use cases?
replyAt my job, all of our business logic (4 KLOC of network topology algorithms) is written in a niche query language, which we have been migrating to PostgreSQL. When an inconsistency/error is found, tracking it can take days, manually commenting out parts of query and looking at the results.
Am not the person you asked, but feel that it could have good value for education and learning as well, besides debugging.
replyIs this postgres only? What an interesting idea!
replyFor now, yes, but I'll start working on adding support for all other DBs (especially OLAP) as soon as possible. The geberal approach is the same, I just have to handle all the edge cases of the SQL dialects
reply