We’ve got a Postgres database with a table that takes heavy select, update and inserts that needs some tuning (it has too many indexes).
We have a read replica, and I’m wondering if moving all of our SELECT queries over to the replica will be a quick win while we sort out the indexes performance. (Our application can be switched over to a replica fairly easily while sorting the indexes is going to take longer).
My understanding is that pointing read operations at the replica probably won’t improve performance in this case, but wanted to check my understanding.
My understanding is that:
- INSERT and UPDATE operations will return once they’re committed to memory (which is then written to the WAL asynchronously), so they’ll be not much faster.
- The replica will stream the WAL and will have to update it’s own copy of the tables and indexes. So SELECT operations on the replica will have to contend with the same IO and CPU demands that those updates impose on the primary, so will gain no performance.
If our app were simply streaming inserts, then I could see a performance improvement for the inserts, but in practice since the clients are performing SELECT/INSERT together, I can’t see a real performance gain here in this use case?
Is this correct, or have I missed something?