Re: [HACKERS] Vacuum Delay feature
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.Jan, three questions. First, is this useful now that we have the new
cache replacement code, second, do we need this many parameters (can't
any of them be autotuned), and third, what about documentation?
You mean if stopping to nap is useful when a signal is pending or if
napping during vacuum itself is useful at all?
I am willing to make it all self tuning and automagic. Just tell me how.
Documentation is missing so far. Will work on that.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Import Notes
Reply to msg id not found: 200402122038.i1CKcZ206272@candle.pha.pa.usReference msg id not found: 200402122038.i1CKcZ206272@candle.pha.pa.us
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.Jan, three questions. First, is this useful now that we have the new
cache replacement code, second, do we need this many parameters (can't
any of them be autotuned), and third, what about documentation?You mean if stopping to nap is useful when a signal is pending or if
napping during vacuum itself is useful at all?I am willing to make it all self tuning and automagic. Just tell me how.
I was hoping you would have some ideas. :-)
I guess my question is that now that we have the new cache replacement
policy, is the vacuum delay worth while. I looked at
http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem
useful.
Documentation is missing so far. Will work on that.
Cool.
--
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, Pennsylvania 19073
Centuries ago, Nostradamus foresaw when pgman@candle.pha.pa.us (Bruce Momjian) would write:
I guess my question is that now that we have the new cache
replacement policy, is the vacuum delay worth while. I looked at
http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem
useful.
They satisfy quite separate use cases, so both are surely useful.
- The new cache replacement policy allows us to make sure that cache
isn't getting blown on worthless things.
- Vacuum delay allows us to make sure that we aren't spending all our
I/O on vacuuming.
There is overlap between their uses, as both should help diminish the
use of I/O to fill buffers with data that was discarded, but they
surely have separate uses.
--
"cbbrowne","@","acm.org"
http://www.ntlug.org/~cbbrowne/lisp.html
You know that little indestructible black box that is used on
planes---why can't they make the whole plane out of the same
substance?