since its always a float

Yeah it's not ideal, but if I was maintainer I'd probably go for that 😄

@User do you have autovacuum turned on and have you confirmed that it has been running? we can reproduce the dichotomy in query latency just by inserting a bunch of rows and running the query without an

analyze

call first

@User ^

> do you have autovacuum turned on and have you confirmed that it has been running Yes and yes, I've also ran ANALYZE manually

@User repro: https://dbfiddle.uk/?rdbms=postgres_14&fiddle=aca524d3e04a431f8a36742401db4071

Yep 👍 that's exactly what I did to reproduce on my side

I'll bubble that up to the Postgres people, a bad query plan is a bug

so, i have several hundred thousand write operations that i need to perform in spicedb in order to backfill some data. i'm assuming that it's not a good idea to run a single

WriteRelationships

request with all of them 😝 but i'm wondering if there is an ideal chunk size to break them up into.

I did a backfill with batches of 1000 and it worked fine IIRC

1000 it is

Lmk how it goes

It will be somewhat datastore dependent

ah that makes sense. we're using postgres

thank you!

just hypothetically, if we split up that process into one

WriteRelationships

call per record, would that have any adverse downstream effects besides just taking longer to finish?

It will generate more transaction rows in your database, should be fine though

okay cool good to know. thanks again

On the same subject ☝️ a piece of feedback: I'm finding it tedious that there's no "delete by filter" operation in

WriteRelationship

, which would allow batching these deletes with other writes. About half of my operations are such "delete by filter", so I'm having to make an API call per relationship which is very very slow, it's taking multiple days to write my production dataset

there is a delete by filter!

Yes, but it's a different endpoint: I'd like to be able to batch these delete by filter with creates and touches

oh interesting

that would imply that it's more of a regular "in response to a user action" request, can you elaborate on the use case?

Sure! We're using event-sourcing. An event might lead to a write into SpiceDB (

access_granted

or

user_created

or similar), or it might lead to a delete (

access_revoked

,

user_deactivated

). Sometimes both (

user_role_updated

). That's done by a Kafka consumer. I have a backlog of a few hundred million events to go through before it has caught up and starts processing new events in near-real-time, and at the moment I'm having to make at least 1 API calls per event: if

WriteRelationships

supported deletes by filter, I could process these events by batch which probably would be much much faster

Is that clear?

We just published a blog post on SpiceDB's little-known HTTP API. https://authzed.com/blog/authzed-http-api/

I tested starting spicedb with this args

--datastore-conn-uri="postgres://postgres:password@localhost:5432/spicedb?sslmode=disable&plan_cache_mode=ffff

. It gave me this error.

Server error (FATAL: invalid value for parameter \"plan_cache_mode\": \"ffff\" (SQLSTATE 22024

But when i pass it with valid value like this.

--datastore-conn-uri="postgres://postgres:password@localhost:5432/spicedb?sslmode=disable&plan_cache_mode=force_custom_plan`?

Spicedb starts without complaining. I'm guessing pgx took the settings.

re: https://discord.com/channels/844600078504951838/844600078948630559/954042344905244694 Do you want me to open an issue on GitHub?