hello @UAEV0STAA, its recommended that you use at least a memory cache so you get that slow first but later fast processes. if you want to persist the cache on disk to avoid that first one you can also do it by implementing a custom cache store that saves and loads from disk

its probably a good idea to make that cache store also read from memory, so you don't have to keep hitting the disk (load from disk once, save in some atom, re-use when the cache key is the same)

here you can find some examples to write a custom cache store: https://pathom3.wsscode.com/docs/cache

let me know if you need any help to make one for the planner

Thank you for the input! Hopefully I have time tomorrow to read it and try it out. I’ll get back asap 😃

is the planner performance supposed to grow like that? that would mean there's a pretty small practical limit on the # of resolvers regardless of caching

hello @U797MAJ8M , this grow is related to the n o resolvers that participates in the same planning, @UAEV0STAA pointed he has one resolver per attr there, which is not ideal, bundling them in less resolvers would prob be quite better (maybe one per table? but really depends on hwo things fit together)

Im my specific case I decided to remove resolvers to some database attributes as they are not identifiers for something. My take now will be to try to "record" a couple of known queries to build up the cache and then persist it so it can be reused over application restarts.

still, don't you think the growth from 87->96 is unusually sharp? I wonder why there's such an inflection point. I could see 90 resolvers being hit in some big queries

I dont think you can use this number in a generalized way, it really depends the relations, number of repetitios for the same attr, nested inputs, optional inputs…

yeah, I guess you would have to print out the planning steps to really see where the problem might be

I just think the cache warming strategy sounds like an unfortunate hack

I really dont see that as a hack, the design expects recurrent queries in cases that requires more performance, and the fact that the planner can cache the plan for those concurrent transactions is what gives me wiggle room for its processing, which can get quite complex depending on the user setup

ah sorry I misread, thought @UAEV0STAA was having to modify his queries, like making smaller ones and then joining them together outside of pathom for some reason

but good to know that async planning is within design 🙂

Hi @UAEV0STAA - if you have a resolver per attribute, then doesn't that mean that for any given entity you will have (n) queries being executed, where (n) is the number of attributes in any given entity. I generally use a resolver per fetch, and sometimes will fetch across tables to reduce needless database hits when I know one attribute is usually needed with another, even when nested, or when I want to build my property graph in a slightly different shape to the underlying database.

@U013CFKNP2R yeah I get multiple resolvers for the same entity and not all of the resolvers are identifiers for the entity. My approach here was maybe a bit naive as I thought that I just generate resolvers for everything. I have this map where I translate attributes into the graph. And I first didnt know if I would query it from :ServerA.Player/id or :player/id

{:ServerA.Player/id :player/id ; maps attribute into the graph
 :ServerA.Player/name nil}     ; doesnt map attribute into the graph

To make it more clear. I generate resolvers for every attribute, but the map tells what attributes that contains the same value and can match. And in most cases it's those mappings that I will be my starting point, but not always.

I have 208 resolvers/operations currently and have no performance issues. I don't think I quite understand how you've set up your resolvers per-attribute sorry.

Happy to look at some code if you have it…

I’ll add, too, that we have well over 100 resolvers and are not seeing any king of degradation like that in performance. In production we absolutely have the planner cache turned on, but in development, the planner’s impact is still negligible.

At the moment the code is very coupled with our data and I don't think it's a good idea to share it as is. Sense I turned on the cache it works just fine for me.

@U0HJA5ZQT I think it really depends on the resolvers inputs/outputs, in my case the planning alone is 500ms 😞