Fixed
Pinned fields
Click on the next to a field label to start pinning.
Details
Assignee
Pierre RegazzoniPierre RegazzoniReporter
Kamini JagtianiKamini JagtianiIs this a Regression?
UnknownTriage
UntriagedStory Points
1Priority
MajorInstabug
Open Instabug
Details
Details
Assignee
Pierre Regazzoni
Pierre RegazzoniReporter
Kamini Jagtiani
Kamini JagtianiIs this a Regression?
Unknown
Triage
Untriaged
Story Points
1
Priority
Instabug
Open Instabug
PagerDuty
PagerDuty
PagerDuty
Sentry
Sentry
Sentry
Zendesk Support
Zendesk Support
Zendesk Support
Created July 13, 2022 at 4:06 PM
Updated October 7, 2022 at 8:55 AM
Resolved July 15, 2022 at 9:20 PM
Summary:
When running the following
UNNEST
query via CBQ when a query memory quota is in place, the query returns partial results and aRequest has exceeded memory quota
error.When running the same query with
LIMIT n
(in this case we usedLIMIT 55
, though this was also seen withLIMIT 32
in a different cluster) the query runs successfully.When running the same query again with
LIMIT n+1
(we usedLIMIT 56
), the query returns an error andusedMemory
is significantly higher. There seems to be a point n, where usedMemory increases significantly, eg:No LIMIT clause:
LIMIT n used (55 in this example):
LIMIT n+1 used (56) (
usedMemory
is significantly higher):The value of n where the issue starts to occur seems to be different in different clusters.
Steps To Reproduce:
Spin up a test cluster.
Deploy the
travel-sample
bucket.On UI under Settings -> Advanced Query Settings -> Memory Quota
set the limit to 400 MB.
* Execute the following query from CBQ:
* Observe the query returns an error and `usedMemory` is high, with partial results returned:
* Try the same with a high LIMIT clause (I used LIMIT 56) and observe the query also returns the same error:
* Run the query again with lower LIMIT values iteratively, eventually there seems to be a point n where the query runs successfully with no error (this was LIMIT 55 in my cluster):
* Ie. LIMIT 55 works, but LIMIT 56 doesn't.
Everything below 55 also works, and everything above 56 doesn't.
This point seems to be different on different clusters - saw the same issue where LIMIT 32 (and below) worked but LIMIT 33 (and higher) showed the issue on a different cluster.
Might require testing different values of LIMIT n to reproduce the issue.