Re: Experimental patch for inter-page delay in VACUUM
От | Hannu Krosing |
---|---|
Тема | Re: Experimental patch for inter-page delay in VACUUM |
Дата | |
Msg-id | 1067813484.3357.20.camel@fuji.krosing.net обсуждение исходный текст |
Ответ на | Re: Experimental patch for inter-page delay in VACUUM (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane kirjutas P, 02.11.2003 kell 20:00: > Jan Wieck <JanWieck@Yahoo.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
В списке pgsql-hackers по дате отправления: