logoalt Hacker News

wood_spirityesterday at 7:45 PM1 replyview on HN

Of course mainstream ORMs leave a lot of perf on the table. For example, I once patched the ORM in a struggling php web app that i had to help. I started as a logger profiler thingy but then had the crazy idea of being a trace optimiser. By recognising the call sites from previous visits I could spot the 1+N and select * etc and actually transcode that into better sql in the next run etc. Shockingly it made a massive difference and I was surprised that normal ORMs aren’t doing that kind of thing.


Replies

stephenyesterday at 10:55 PM

> trace optimizer/better sql in the next run

Ah wow! I admittedly already linked this PR in another reply, but I'm trying similar things here:

https://github.com/joist-orm/joist-orm/pull/1967

Neat to hear you had success with it before; did you have to handle "the optimization was inaccurate [a novel codepath asked for a column we didn't return], so fallback to `select *`"? And do that without failing the overall request?

This "fallback and implicit retry" is what I'm doing atm, and just assuming is the only way of handling the "novel codepath was hit this time" problem, but lmk if I'm missing something.