undefined

points

by dkhenry11 hours ago |

comments

by kiwicopple10 hours ago|

[-]

Thanks for verifying the benchmarks. We’re close to a full RC, aiming for December

Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us

by Sesse__10 hours ago|

parent|

[-]

I assume you get this a lot, but how much patching is left in PG 18?

by kiwicopple10 hours ago|

parent|

[-]

We are tracking the patches here:

https://www.orioledb.com/docs#patch-set

The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.

I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)

by Sesse__10 hours ago|

parent|

[-]

OK, so basically no big change with PG 18, and for the time being, one needs to basically your own Postgres?

Would be really nice with a pgdg package, as this is definitely the kind of thing I would want to test in a separate cluster :-)

by btown9 hours ago|

prev|

[-]

Based on the README [0] and discussion [1] it seems like it might especially shine on high-write-volume workflows, with the implementation of anti-bloat measures. Do you have a sense for whether it would shine even further where those rows have large text/JSONB fields that might be TOASTed?

And more generally, curious if you have any sense for what might make up the "1%" of workflows this wouldn't be advisable for? Any downsides to be aware of?

[0] https://github.com/orioledb/orioledb?tab=readme-ov-file#orio...

[1] https://news.ycombinator.com/item?id=30462695 (2022)

by dkhenry8 hours ago|

parent|

[-]

I haven't explicitly tested how it handles TOASTed column's, but since there is an upcoming RC I will try it out next time. I don't generally like using JSONB/text columns for very large rows as they have other performance problems on the DB like causing lots of WAL write overhead.

In term of other workloads it might not be great for, all my testing has shown a great improvement in every workload I have thrown at it.

by benjiro2 hours ago|

prev|

[-]

OrioleDB looks interesting but the with the storage changes, the issue will be the compatability with other extensions. pg_search (paradedb), timescale come to mind.

We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.

by pella1 hours ago|

parent|

[-]

As far as I know, you can run heap and orioledb tables side by side in the same system, so I don’t see a problem using heap-based extensions like timescale together with orioledb. ( of course timescale doesn’t support OrioleDB storage yet, but they can run in parallel. )

and many extensions (e.g. postgis) already work fine with OrioleDB storage.