Millions of erroneous row reads from a count statement with Prisma and planetscale
Does anyone know why this is the case
14 Replies
The planetscale site says this: https://i.vgy.me/guWss3.png
Does this mean getting count for paginate is effectively one query? For cost stuff
They're probably using internal table stats the db engine keeps a count of as the estimation
So that it avoids doing a full table scan
Also planetscale is distributed right? Might also make that query harder and less accurate
Depending on default locks
I don't know much about mysql/vitess internals but that's my guess
wonder why its registering millions of row reads on my dashboard
Is it?
I've never tried planetscale and I was worried about this use case to host my own.
TBH in most scenarios an good enough estimate of count is preferred over full table scan.
yeah I looked at my dashboard and millions of queries are coming from a count statement
even though their site says counts shouldn't increase row reads (for billing purposes)
do you filter at all?
I did use a
where with prismaI wonder if the count(*) is only for the full version and not for a filter (unless you perhaps have an index on the where clause?)
interesting, you could be right
but that would be very weird
id followup with planetscale support
I literally just have a pageview table and want to count the pageviews where page slug == slug in the db
yeah I might have to
ive removed that line of code for now 😂
don't want to chew up the rest of my queries for the month
id ask and mention what you did
they might refund you
hopefully, unless I didn't read that page correctly 😂