| From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Luke Lonergan <llonergan(at)greenplum(dot)com> |
| Subject: | Re: Sync Scan update |
| Date: | 2006-12-30 19:35:05 |
| Message-ID: | 20061230193504.GO71246@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 19, 2006 at 10:37:21AM -0800, Jeff Davis wrote:
> > leader is doing a nested loop and the follower which is just doing a straight
> > sequential scan is being held back?
> >
>
> The follower will never be held back in my current implementation.
>
> My current implementation relies on the scans to stay close together
> once they start close together. If one falls seriously behind, it will
> fall outside of the main "cache trail" and cause the performance to
> degrade due to disk seeking and lower cache efficiency.
That's something else that it would be really good to have data for; in
some cases it will be better for the slow case to just fall behind, but
in other cases the added seeking will slow everything down enough that
it would have been faster to just stay at the speed of the slow scan.
The question is where those two thresholds are...
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2006-12-30 19:44:28 | Re: TODO: GNU TLS |
| Previous Message | Stephen Frost | 2006-12-30 19:28:10 | Re: TODO: GNU TLS |