williamdclt
03/15/2022, 5:03 PMEXPLAIN ANALYZE
which could show us what SpiceDB is doing with a permissionCheck request?fukuroutoimasu
03/15/2022, 5:05 PMfukuroutoimasu
03/15/2022, 5:07 PMwilliamdclt
03/15/2022, 5:08 PMdispatch
calls and couldn't understand what they related to (it's been a few days, I don't remember exactly)fukuroutoimasu
03/15/2022, 5:11 PM--debug
and it'll return the dispatch count and cached count. You can see how complex the query is and if it is being cached at all that way.
Fundamentally, complex queries are broken down into subproblems and dispatched to nodes that are assigned to store them in their cache. The more complex the query, the more subproblems there are.fukuroutoimasu
03/15/2022, 5:15 PMwilliamdclt
03/15/2022, 5:21 PM--debug
thanks!
Going back to the original question: is it unreasonable to expect SpiceDB to give a <10ms P50, and <50ms P99 for ~7M relations? I'm sure that's not enough information to give a good answer, but is there any way I can have a rough idea of what I should be expecting from SpiceDB in terms of performances?fukuroutoimasu
03/15/2022, 5:29 PMwilliamdclt
03/15/2022, 5:31 PMfukuroutoimasu
03/15/2022, 5:32 PMwilliamdclt
03/15/2022, 6:27 PMSELECT MIN(id), MAX(id) FROM relation_tuple_transaction WHERE timestamp >= $1
I only have read traffic, no write. When it starts going into this pattern, all checks take multiple minutes (and might be timeout-ing).
That looks like a bug in spicedb?williamdclt
03/15/2022, 6:47 PMEXPLAIN ANALYZE
for it:
Result (cost=1.07..1.08 rows=1 width=16) (actual time=28103.240..28103.242 rows=1 loops=1)
InitPlan 1 (returns $0)
-> Limit (cost=0.43..0.54 rows=1 width=8) (actual time=28103.219..28103.220 rows=1 loops=1)
-> Index Scan using pk_rttx on relation_tuple_transaction (cost=0.43..193195.54 rows=1823603 width=8) (actual time=28103.218..28103.218 rows=1 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= '2022-03-15 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 548517
InitPlan 2 (returns $1)
-> Limit (cost=0.43..0.54 rows=1 width=8) (actual time=0.016..0.016 rows=1 loops=1)
-> Index Scan Backward using pk_rttx on relation_tuple_transaction relation_tuple_transaction_1 (cost=0.43..193195.54 rows=1823603 width=8) (actual time=0.015..0.015 rows=1 loops=1)
Index Cond: (id IS NOT NULL)
Filter: ("timestamp" >= '2022-03-15 00:00:00'::timestamp without time zone)
Planning time: 0.375 ms
Execution time: 28103.275 ms
ecordell
03/15/2022, 6:53 PMdatastore-revision-fuzzing-duration
flag?ecordell
03/15/2022, 6:54 PMwilliamdclt
03/15/2022, 6:57 PMecordell
03/15/2022, 7:00 PMix_relation_tuple_transaction_by_timestamp
but from the explain output it doesn't look like that's being usedecordell
03/15/2022, 7:00 PMwilliamdclt
03/15/2022, 7:09 PM1.4.0
. The index does exist, but indeed isn't used: PG has to choose whether to use the index on id
(to speed up one of MIN
or MAX
), or the index on timestamp
to speed up the filtering.
Adding this index seems to solve it, at least in the query plan:
CREATE INDEX CONCURRENTLY rttx_timestamp_id ON relation_tuple_transaction(id, "timestamp");
Jake
03/15/2022, 7:16 PMid
helps with MIN(id)
or MAX(id)
with a where clauseJake
03/15/2022, 7:16 PMJake
03/15/2022, 7:16 PMJake
03/15/2022, 7:18 PMANALYZE
on the db?Jake
03/15/2022, 7:18 PMwilliamdclt
03/15/2022, 7:21 PMwilliamdclt
03/15/2022, 7:22 PMJake
03/15/2022, 8:08 PM5s
of datasleipnir042
03/15/2022, 8:43 PMPERMISSIONSHIP_HAS_PERMISSION
the API proceeds.sleipnir042
03/16/2022, 1:30 PMPERMISSIONSHIP_UNSPECIFIED
?Joey
03/16/2022, 1:31 PMsleipnir042
03/16/2022, 1:31 PM