Re: Experimental patch for inter-page delay in VACUUM
От | Bruce Momjian |
---|---|
Тема | Re: Experimental patch for inter-page delay in VACUUM |
Дата | |
Msg-id | 200311101852.hAAIqYe22653@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Experimental patch for inter-page delay in VACUUM (Jan Wieck <JanWieck@Yahoo.com>) |
Список | pgsql-hackers |
Jan Wieck wrote: > Bruce Momjian wrote: > > > Tom Lane wrote: > >> Andrew Sullivan <andrew@libertyrms.info> writes: > >> > On Sun, Nov 02, 2003 at 01:00:35PM -0500, Tom Lane wrote: > >> >> 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. > >> > >> > I know there are severe disadvantages in the current implementation, > >> > but are there in-principle severe disadvantages? > >> > >> Yes. For one, since we cannot change the size of shared memory > >> on-the-fly (at least not portably), there is no opportunity to trade off > >> memory usage dynamically between processes and disk buffers. For > >> another, on many systems shared memory is subject to being swapped out. > >> Swapping out dirty buffers is a performance killer, because they must be > >> swapped back in again before they can be written to where they should > >> have gone. The only way to avoid this is to keep the number of shared > >> buffers small enough that they all remain fairly "hot" (recently used) > >> and so the kernel won't be tempted to swap out any part of the region. > > > > Agreed, we can't resize shared memory, but I don't think most OS's swap > > out shared memory, and even if they do, they usually have a kernel > > We can't resize shared memory because we allocate the whole thing in one > big hump - which causes the shmmax problem BTW. If we allocate that in > chunks of multiple blocks, we only have to give it a total maximum size > to get the hash tables and other stuff right from the beginning. But the > vast majority of memory, the buffers themself, can be made adjustable at > runtime. That is an interesting idea. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: