zlacker

>>redbel+(OP)

  "In Python, most of the bottleneck comes from having to fetch and deserialize Redis data."

This isn't a fair comparison. Of freaking course postgres would be faster if it's not reaching out to another service.

>>chaps+b5
Yes, that's essentially the point being made here. It's a fair comparison if your intent is to run this kind of job as quickly as possible.

>>redhal+c7
No it's not. It tells me exactly nothing useful about the postgresml performance because it's impossible for me to rule out redis and the http server when factoring in performance. It's two hops, with a guaranteed delay that the postgres setup won't have.

If they wanted it to be a fair comparison they should have used FDWs to connect to the same redis and http server that the python benchmarks tested against.

>>chaps+P7
The point is you don't need those hops if you use postgresML.

It's like if I told you to move to a place where you can walk 5mins to work, and you tell me it's not a fair comparison because right now you have to drive to the station and then get on a train and you're interested in a comparison where you walk to the train instead. You don't need the train because you're already there!

You don't need the network hops exactly because the data is already there in the right way.

>>vasco+v8
You don't need those hops if you use Python either. Python runs inside Postgres.

https://www.postgresql.org/docs/current/plpython.html

Naturally Rust or C functions will still be faster.

>>FreakL+vr
PostgresML v1.0 was doing exactly that. When we rewrote in Rust for v2.0, we improved 35x: https://postgresml.org/blog/postgresml-is-moving-to-rust-for...