Serhii Tatarintsev

I tried replacing `create` call with `queryRaw(SELECT 1)` and connection still got slower over time: from 62ms for the first to 237ms for the last. Trace is attached. [trace-select.json.zip](https://github.com/prisma/prisma/files/9558542/trace-select.json.zip)

And another trace with individual identifiable spans for each request. [anotatated-trace.json.zip](https://github.com/prisma/prisma/files/9559238/anotatated-trace.json.zip)

Still happens on current `main` (4.4.0-dev.46) [Reproduction](https://github.com/prisma/reproductions/tree/main/gh-10331)

Still reproduces as of current `main` (`4.4.0-dev`). [Somewhat simpler reproduction](https://github.com/prisma/reproductions/tree/main/gh-9234). It reproduces with library engine, but not with binary.

Same on 2.x: works with binary engine, does not with library. So, I'd say, because of the switched defaults it is a regression.

Done as a part of PDP Tracing

@zgajo could you share your schema? Computed fields should appear on all `BarberWorkTimeOverride` models, regardless of where it appears - top level or deeply nested relation.

@zgajo I've just checked that and this code works correctly for me: ```ts const prisma = new PrismaClient().$extends({ result: { barberWorkTimeOverride: { end: { compute(barberWorkTimeOverride) { const date = moment(barberWorkTimeOverride.date).format('YYYY-MM-DD')...

Hey everyone. I am sorry, but after internal discussion we decided to close this PR. While we are not strictly against this feature and would like to provide the support...

I think GH actions still use `stable` toolchain and ignore `rust-toolchain.toml`