Skip site navigation (1) Skip section navigation (2)

Re: Sync Scan update

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
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: 2007-01-02 17:48:22
Message-ID: 1167760102.14243.14.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, 2006-12-30 at 13:35 -0600, Jim C. Nasby wrote:
> > 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...

Right. I will do more testing for my basic patch soon, but a lot of
testing is required to characterize when the scans should move apart and
when they should stay together. The problem is that there are a lot of
variables. If you have a few scans that uses a moderate amount of CPU,
the scans might all stay together (I/0 bound). But as soon as you get
more scans, those scans could all become CPU bound (and could be mixed
with other types of scans on the same table).

If you have some ideas for tests I can run I'll get back to you with the
results. However, this kind of test would probably need to be run on a
variety of hardware.

	Jeff Davis

In response to


pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2007-01-02 18:04:46
Subject: Re: TODO: Add a GUC to control whether BEGIN inside
Previous:From: Tom LaneDate: 2007-01-02 17:33:25
Subject: Re: TODO: Add a GUC to control whether BEGIN inside

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group