feat: query compiler proof of concept

[aqrln]

Separate query planning and execution and lower the query graph into a format executable by the client.

Translates, for example,

  prisma.user.findMany({
    where: {
      createdAt: {
        gt: Prisma.Param('startDate'),
      },
    },
  })

to

{
  query {
    SELECT `main`.`User`.`id`, `main`.`User`.`email`, `main`.`User`.`createdAt` FROM `main`.`User` WHERE `main`.`User`.`createdAt` > ? LIMIT ? OFFSET ?
  } with [Placeholder { name: "startDate", type: Date }, Int(-1), BigInt(0)];
}

which is then executed by the QueryInterpeter on the client.

Processing query graphs with more than one node is work in progress. Functions in the edges (data dependencies) can be executed at compile time thanks to the new Placeholder abstraction (we can algebraically substitute future values not yet fetched from the database into the inputs of downstream graph nodes and continue building the query with them before those values actually exist). Flow and computation nodes need to be redesigned though.

Client: prisma/prisma#25511

[github-actions]

WASM Query Engine file Size

Engine	This PR	Base branch	Diff
Postgres	1.262MiB	2.044MiB	-800.954KiB
Postgres (gzip)	505.784KiB	821.587KiB	-315.804KiB
Mysql	1.238MiB	2.011MiB	-791.441KiB
Mysql (gzip)	497.952KiB	808.684KiB	-310.733KiB
Sqlite	1.217MiB	1.910MiB	-709.772KiB
Sqlite (gzip)	488.534KiB	769.892KiB	-281.359KiB

[codspeed-hq]

CodSpeed Performance Report

Merging #5024 will not alter performance

_{Comparing compiler (3668ee0) with main (cc0167b)}

Summary

✅ 11 untouched benchmarks