Serious performance issue when executing SELECT queries

Bug description

I am experiencing a huge discrepancy in query execution time when using prisma 3.8.0 with postgres (local installation). When I query a large table made of simple records and use pagination params (skip and take) this query takes a very long time to execute via prisma.<model>.findMany however when I use a similar query with prisma.queryRaw the execution time is much less. Normal prisma queries are dramatically slower.

The model I use is very simple and defined as follows

model StringIdModel {
    id    String @id @default(uuid())
    value String
}

Assuming the database table is filled with 1M random records and I run tthis code:

const queryLimit = 1000;
const queryOffset = 950000;
await prisma.stringIdModel.findMany({ skip: queryLimit, take: queryOffset });
await prisma.$queryRaw`SELECT * FROM public."StringIdModel" LIMIT ${queryLimit} OFFSET ${queryOffset}`;

This is the result I get

findMany took 10938.153129ms.
queryRaw took 84.126091ms.

As you can see the difference is 130 (!) times. I have tried running this many times with different ID column types, different dataset sizes and I can’t see any other reason why this is the case. The only thing I can think of is something going wrong inside prisma.

Here’s a repo that reproduces the problem https://github.com/peterrogov/prisma-performance-test

How to reproduce

Use the following repository that has code with reproduction https://github.com/peterrogov/prisma-performance-test

OR

1. Create a simple model that only has ID field and maybe a single scalar field.
2. Deploy to DB and fill with random data (I use like 1M records)
3. Run query with prisma.<model>.findMany and specify skip and take params. Provide skip and take such that you’re fetching from the end of the dataset. Measure query execution time.
4. Make the same query but now use prisma.queryRaw and make query like SELECT * FROM ... OFFSET ... LIMIT .... Run the query and measure execution time
5. See the huge difference in time.

Expected behavior

There shouldn’t be any significant difference executing such simple queries directly via SQL or via prisma methods. The time it takes a query with prisma must be close to a direct raw SQL.

Prisma information

@prisma/client 3.8.0

Environment & setup

PostgreSQL 12.4 MacOS 11.6.2 NodeJS 17.3

Prisma Version

prisma                  : 3.8.0
@prisma/client          : 3.8.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
Studio                  : 0.452.0

[janpio]

@georgekrax That does not look right, but it completely unrelated to the issue you are responding to. Please open a new issue, include a bit more information so we can hopefully reproduce and we are happy to look into this.

[peterrogov]

@janpio I agree with you on this one. I was investigating another issue (#11138) when I stumbled upon this. Initially I failed to realise the huge difference between using and not using ORDER BY. That’s where 130x gap came from.