> Inlining output fetching does not quite have the performance impact I
> was hoping for.  For example, /api/queue remains quite slow (sometimes a
> tenth of a second but often several seconds.)  The problem might be
> elsewhere though, perhaps some Fiber scheduling issue.

Hmm, we could examine the query plan and see what's up with it.

I don't think this specific SELECT can be made any faster anymore by
rewriting the SELECT - but maybe by adding indices or reordering data
(index statistics).