"Simon Riggs" <[EMAIL PROTECTED]> writes: > Like to see some tests with 2 parallel threads, since that is the most > common case. I'd also like to see some tests with varying queries, > rather than all use select count(*). My worry is that these tests all > progress along their scans at exactly the same rate, so are likely to > stay in touch. What happens when we have significantly more CPU work to > do on one scan - does it fall behind??
If it's just CPU then I would expect the cache to help the followers keep up pretty easily. What concerns me is queries that involve more I/O. For example if the leader is doing a straight sequential scan and the follower is doing a nested loop join driven by the sequential scan. Or worse, what happens if the leader is doing a nested loop and the follower which is just doing a straight sequential scan is being held back? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
