Oliver Rice

hmm! unfortunately I haven't been able to reproduce that behavior The transpile step on your query wouldn't account account for more than a few milliseconds in the worst case so...

> Yup this is reproducible on the free tier: odiercuj......... thank you, that's prefect. I am able to reproduce the issue and am working towards isolating the source of the...

Sorry for the delay. I recreated your query locally and am similarly getting 500-600 ms. > The transpile step on your query wouldn't account account for more than a few...

thank you, I was able to reproduce in the short term, separating forward and backward pagination queries should avoid the error message

GraphQL queries are more flexible than prepared statements in that you can control things like result ordering via a variable. The first time a query is executed the query builder...

so sorry for the delay getting back to you! that isn't usual, I had notifications misconfigured There will likely be a `node` interface once a global id has been implemented...

that you for reporting, I was able to reproduce the issue When casting inputs from GraphQL types to PostgreSQL types pg type modifiers are ignored (except for arrays). That is...

sorry for the huge delay getting back to you! that isn't normal, my notifications were off on accident Okay (for internal reference), here's a quick repro case for the error...

thanks for the ping! I'm leaning away from exposing string pattern filters String matching is very flexible and notoriously difficult to index for. With the exception of functional indexes exactly...

> how are you imagining handling search use cases there? The the short term, search would be limited to filtering on a list of strings. Longer term we may -...