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

Re: Experimental patch for inter-page delay in VACUUM

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-02 22:51:24
Message-ID: 1067813484.3357.20.camel@fuji.krosing.net (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane kirjutas P, 02.11.2003 kell 20:00:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > I am currently looking at implementing ARC as a replacement strategy. I 
> > don't have anything that works yet, so I can't really tell what the 
> > result would be and it might turn out that we want both features.
> 
> It's likely that we would.  As someone (you?) already pointed out,
> VACUUM has bad side-effects both in terms of cache flushing and in
> terms of sheer I/O load.  Those effects require different fixes AFAICS.
> 
> One thing that bothers me here is that I don't see how adjusting our
> own buffer replacement strategy is going to do much of anything when
> we cannot control the kernel's buffer replacement strategy.  

At least for OpenSource/Free OS'es it would probably be possible to
persuade kernel developers to give the needed control to userspace apps.

So the "take over all RAM" is not the only option ;)

> To get any
> real traction we'd have to go back to the "take over most of RAM for
> shared buffers" approach, which we already know to have a bunch of
> severe disadvantages.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2003-11-02 23:06:45
Subject: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL
Previous:From: Fabrizio MazzoniDate: 2003-11-02 22:42:28
Subject: pgsql crosstab function

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