From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
Subject: | Re: Sync Scan update |
Date: | 2006-12-19 18:05:43 |
Message-ID: | 87lkl3kbgo.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Carlo Stonebanks | 2006-12-19 18:06:48 | ODBC: how to change search_path in DSN? |
Previous Message | Jeff Davis | 2006-12-19 18:03:13 | Re: Sync Scan update |