http://kerneltrap.org/node/view/715
Might be interesting for people running 2.6. Last I heard, the anticipatory
scheduler did not yield it's maximum throughput for random reads. So they said
database guys would not want it right away.
Anybody using it for testing? Couple of guys are running it
On Mon, 2003-08-11 at 19:50, Christopher Kings-Lynne wrote:
> > Well, yeah. But given the Linux propensity for introducing major
> > features in "minor" releases (and thereby introducing all the
> > attendant bugs), I'd think twice about using _any_ Linux feature
> > until it's been through a majo
On Mon, 2003-08-11 at 17:03, Josh Berkus wrote:
> Folks,
>
> More followup on this:
>
> The crucial difference between the two execution plans is this clause:
>
> test db has:
> -> Seq Scan on case_clients (cost=0.00..3673.48 rows=11274 width=11) (actual
> time=0.02..302.20 rows=8822 loops=85
> be able to handle at least 8M at a time. The machine has
> two P III 933MHz CPU's, 1.128G RAM (512M*2 + 128M), and
> a 36 Gig hd with 1 Gig swap and 3 equal size ext3 partitions.
> What would be the recomended setup for good performance
> considering that the db will have about 15 users for
> 9 h
On 5 Aug 2003 at 10:29, Christopher Browne wrote:
> Shridhar Daithankar wrote:
> > I agree, specifying per table thresholds would be good in autovacuum..
>
> Which begs the question of what the future direction is for pg_autovacuum.
>
> There would be some merit to having pg_autovacuum throw
