3 ms·

I thought we'd be comparing apples-to-apples with Postgres running locally in this case?

• bob1029 4y ago
  Ok - How many microseconds does it take to round trip SELECT 1 to localhost on a typical cloud VM? You are still using the network stack and involving multiple processes.
  • Spivak 4y ago
    People really do be forgetting how unbelievably fast doing things in-process is. It’s why people suffer the complexity of threads instead multiple processes with ipc - like the network.
    • bob1029 4y ago
      Agreed. In-process is where you get things like instruction-level parallelism. I think our university programs have failed us the most in this regard. ILP should be drilled into every student's brain as the penultimate performance hack. Once you start separating everything into a bunch of different buckets/systems/processes, none of these advantages can be explored anymore. In some cases, ILP can give you a 100x improvement in performance. That's serial throughput. This is the reason many developers consider bit manipulation/hacking to be essentially free.
  • linuxdude314 4y ago
    There is no “round trip” and no network stacked involved in querying a local Postgres instance (web app on same VM as db). Attention is better spent designing an appropriate schema than worrying about the network being too slow to run a single query (if it is, you’ve already failed).
  • justinclift 4y ago
    > Ok - How many microseconds does it take to round trip SELECT 1 to localhost on a typical cloud VM? As a data point, when PG is on the same box as the querying app, you can run the connection over a unix domain socket instead of going over localhost. In theory (!), that's supposed to have reduced latency + higher bandwidth too. It's been a bunch of years since I last saw benchmarks about it though, so things might have changed a bit in the meantime (no idea).