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 adarsh.sha...@orkash.com
To:
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
