Thanks Craig.
Yep, I am not seeing the SELECTs slow down (measurably) during checkpoints
(i.e. when dirty pages are flushed to disk), but only during writing of the
WAL
files. The buffers shared and OS are big enough to hold the entire database,
so
evicting cached data should not be necess
Thanks Pavan!
I think the most important points are still that:
1. The WAL write should be happening asynchronously (if that is possible)
2. There should be an option do not perform these compactions if the page is
only touched by reads.
(Assuming that when most of the databaseresides in the ca
No: The commit has the same guarantees as a synchronous commit w.r.t. data
consistency. The commit can only fail (as a whole) due to hardware problems or
postgres backend crashes.
And yes: The client commit returns, but the server can fail later and not
persist the transaction and it will be
Unless you use the explicit join syntax:
select p.* from A p join B q on (p.id = q.id)
and also set join_collapse_limit= 1
The order of the joins is determined by the planner.
Also explain is your friend :)
From: Adarsh Sharma
To: pgsql-performance@postgresq
