tyrelr

Thanks for the perf results. The call to logger.add_result is hashing a Vec, which is also cloned. So that large struct acting as a hash-key is probably the root issue....

After playing with the code for a bit, this looks like a combination of a HUGE number of potential unique paths, exacerbating the inefficient logging code. On my machine I...

That test looks good, but it might be quite a while before I get spare time to poke at it. If you want a quick fix, you probably will want...

This is an interesting idea, and is a much bigger idea than my thought of having a sqlx describe command to inspect the results of a query. I do see...

Note: do not merge until benchmarked. I noticed the sqlite describe 'recursive' unit test taking a bit of time, so it's quite possible this branch has a performance regression.

It does indeed slow things down. I'll need to profile it at some point when I have time see where it was (hoping that it's not the tracking of de-duplicated...

The slow down was from data captured by the logger even when logging was disabled. Fixing that, the performance is comparable to before when not logging (and arguably improved). ```...

Performance is comparable after some code cleanup ``` group 02f196b4 98bc9076 ----- -------- -------- insert/fks 1.01 372.6±4.78µs ? ?/sec 1.00 369.3±5.90µs ? ?/sec insert/returning 1.02 362.1±5.47µs ? ?/sec 1.00 353.8±3.54µs...

> This is really cool, but does the graph generation always run? The generation is tied to the logging level of "sqlx::explain". So both the capture of the data it...

Thanks for the reproducer. I tweaked your reproducer so that I could dump a trace of the potential opcode execution paths, then commented out the execution paths that were irrelevant,...