Discussion on slow queries in Sanity's content calendar plugin with v2021-03-25 API version

18 replies
Last updated: May 7, 2021
Hi, trying to figure out why certain queries take so much longer on the latest api version. The following it 360ms on
v2020-03-25
and 6s on
 v2021-03-25

* [_type == "schedule.metadata" && !(_id in path('drafts.**'))] {
      ...,
      "doc": * [_id == ^.documentId || _id == "drafts." + ^.documentId ][0]
 }
This query is used in the content calendar. I wanted to fix the deprecated usage of the client without version and use the latest one but the query is just way to slow
May 7, 2021, 1:26 AM
I gave this a try and although there were times when the v2021-03-25 API came back slow, there were also times it came back very quickly. How many calendar events are you working with (even approximately)?
May 7, 2021, 3:32 PM
There is one scheduled document
May 7, 2021, 3:34 PM
I gave this a try and although there were times when the v2021-03-25 API came back slow, there were also times it came back very quickly. How many calendar events are you working with (even approximately)?
May 7, 2021, 3:32 PM
Yeah, me too. The longest the query ever took for me was about 1300ms.
May 7, 2021, 3:34 PM
Mine is 6697ms consistently
May 7, 2021, 3:37 PM
How many documents do you have overall?
May 7, 2021, 3:37 PM
120 in this test dataset.
May 7, 2021, 3:38 PM
I have 8653
May 7, 2021, 3:38 PM
Ahh
May 7, 2021, 3:38 PM
And that’s not the production set, which is around 5 times bigger
May 7, 2021, 3:38 PM
So I think there needs to be a better way to query in the calendar plugin as this one clearly doesn’t scale with a newer API. Is there any information on the changes introduces by new api versions?
May 7, 2021, 3:48 PM
The weirdest part… the time is spent on string concatenation it seems. This query is as fast (if not faster) than the older API
* [_type == "schedule.metadata" && !(_id in path('drafts.**'))] {
      ...,
      "doc": * [_id == ^.documentId || _id == ^.documentId ][0]
 }
It’s a contrived example but nonetheless.
May 7, 2021, 4:03 PM
I know this doesn’t solve the actual issue, which is the speed discrepancy between queries on
v1
and
v2021-03-25
, but in
config/content-calendar.json
I’m guessing you set types. Does it help to also include those types in your
doc
filter?
May 7, 2021, 4:44 PM
I know this doesn’t solve the actual issue, which is the discrepancy between
v1
and
v2021-03-25
, but in
config/content-calendar.json
I’m guessing you set types? Does it help to also include those types in your
doc
filter?
May 7, 2021, 4:44 PM
Just checked. Nope. As I said the problem is literally there when there is that string concatenation bit
"drafts." + …
May 7, 2021, 4:47 PM
So it’s actually quite fast otherwise.
May 7, 2021, 4:48 PM
I found the threads where I had seen this before. https://sanity-io-land.slack.com/archives/C9Z7RC3V1/p1617045190025200 and https://sanity-io-land.slack.com/archives/C011CAT70DD/p1617733034066700 . Perhaps you could try Carl’s suggestion of stacking projections.
May 7, 2021, 5:15 PM
I will try this and report
May 7, 2021, 5:41 PM

Sanity– build remarkable experiences at scale

The Sanity Composable Content Cloud is the headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.

Was this answer helpful?