Add caching to JSON schema builder

[implabinash]

Hi everyone,

I am Abinash. I found that the JSON schema validator have to build the schema every single time, you try to update or insert in your table.

jsonschema::is_valid(&schema.0, &instance.0)

So, I think, why not add a simple caching layer with a limit to make the schema check faster, because with a caching layer, if you insert or update millions of rows with the same JSON schema, you don't have to build the schema every single time.

Implementation can be done in a few lines of code with the help of the lru crate (https://crates.io/crates/lru). With this, the binary will only increase by 2-3%, i.e. around 50-100kb, but the performance will be doubled.

If the maintainers think this will be great for the company, I am happy to implement this feature.

Thank you.

[imor]

The idea is valid that caching should improve performance but it'd be great to see some actual numbers. Then there's the question of what the api will look like with caching, e.g. what will be the caching key? Also need to think through the implications of each connection process having their own copy of the cached data.

Happy to review a more fleshed out design or even a PR if you are up for it.

[implabinash]

Thank you.

it's be great to see some actual numbers.

I ran the same benchmarking that was mentioned at the end of the README file.

System Config:

• OS: Ubuntu 24.04.3 LTS on Windows 10 x86_64 (I am using Ubuntu on WSL)
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• CPU: AMD Ryzen 5 7530U with Radeon Graphics (12) @ 1.996GHz
• Memory: 7639MiB
• Postgres Version: pg16

Results I get benchmarking 3 times in a row with --release flag:

No.	Without Cache	With Cache	% improved
01	353.527 ms	221.079 ms	37.47%
02	339.459 ms	218.640 ms	35.58%
03	338.878 ms	213.260 ms	37.07%

what the api will look like with caching

The API for pg_jsonschema will be the same. I just introduced a caching layer, which has a function to check whether the cache exists or not; if not, it will create the validator and save it to the cache.

what will be the caching key?

The key for the cache will be the hash of the schema, and I am using the default hasher, which is faster than the string comparison and has no need of external lib.

One more thing, the default size of the cache will be 100, and afterwards it will use the LRU algorithm to delete the least recently used key.

think through the implications of each connection process having their own copy of the cached data.

I am using a static LRU cache, which is present only within the backend process, not globally to Postgres. It helps repeated validation within the process, but the cap is bounded by the no of keys in the LRU cache, i.e. 100 at most.

Things I have implemented:

• Caching
• functions to clear cache
• get total cache capacity
• get current capacity

Things I have not implemented:

• HIT/MISS ratio
• configurable cache capacity
  (I left these to know maintainers' feedback on the implementation to move forward)

Complete Code: https://github.com/implabinash/pg_jsonschema/blob/feat/caching_for_jsonschema_builder/src/lib.rs

If everything looks good, let me know, and I will raise a PR.

Thank you.

[Stranger6667]

My 2 cents. jsonschema also runs meta schema validation for each new validator, so it could be significant for large / recursive schemas (though I don't have the numbers at hand). On the implementation - building a cache key does not require JSON serialization (though it is a straightforward way to build it) - serde_json::Value implements Hash