Relational query, Planetscale throws: `ResourceExhausted desc = Out of sort memory`
SOLUTION: the problem was that I had a json column storing a massive value on each row.
code = ResourceExhausted desc = Out of sort memory, consider increasing server sort buffer size (errno 1038) (sqlstate HY001)
Possible reasons?
- bloated table: 76
columns, half of type json()
or text()
– but only 228 rows – total db size only 1.61MB
- drizzle relational query over-selecting?
Drizzle relational query:
The logged sql statement selects all 78 columns. Shouldn't it only need need ~two columns for relation lookup?
2 Replies
By adding a where key to my relational query, the query succeeds
where: eq(properties.id, 1234),
Here are my relations definitions
EDIT: https://stackoverflow.com/questions/29575835/error-1038-out-of-sort-memory-consider-increasing-sort-buffer-size
Some mysql users report this error when using large json columns.
So maybe it is related to by ~30 json columns.
My json columns are only storing small array of strings.
But maybe the drizzle query could be optimized to only select the columns necessary for the relation lookup query? (or maybe sql requires it)
In my schema, if I comment out my other 76 properties columns (without db push), the query succeeds! (even as a findMany).
Here is the drizzle logged raw sql:
But if I comment the columns back in, and execute the same raw sql query that only uses the required columns, it fails with the same error:
Because the drizzle query generated from the db.execute(sql``) query does contain the other 76 (many json) columns again
So maybe the issue is a combination of:
- drizzle query is over-selecting
- my table has many json column types (even though the actual data stored in the json is much less than 1.6Mib total)
for now, I will just do multiple select() queries (non relational), since they do not have memory issues
EDIT: Wow, I had a rogue json column storing a massive value on each row. I deleted that and now it's working perfectly 🙌Yes, we are aware that the query selects more columns than it needs to, but that's (probably) related to a bug in the PlanetScale engine that doesn't allow selecting
*
plus additional fields in subqueries - it ignores the *
part in that case and only returns the additional fields. So we had to work around that by selecting all the columns in subqueries.
FWIW, we're gonna think about how to optimize the relational queries generation soon, so maybe something will change for this case as well.