[HACKERS] Changing semantics of autovacuum_cost_limit

can change cost delay setting of workers on-the-fly. This can be achieved by forcing VACUUM refers to the cost delay setting in its worker’s share memory every vacuum_delay_point. Any comments or suggestions? Best Regards Galy Lee [EMAIL PROTECTED] NTT Open Source Software Center

Re: [HACKERS] autovacuum next steps, take 3

orithm needs to ensure each worker can finish their tasks on time, this might resolve the headache HOT table problem. But this is a further issue to be discussed after 8.3. Best Regards Galy Lee lee.galy _at_ oss.ntt.co.jp NTT Open Source Software Center -

Re: [HACKERS] autovacuum next steps, take 3

d | relid | group --+---+---+--- 1001 | 2 | 20001 | 0 1002 | 3 | 30001 | 0 Best Regards Galy Lee lee.galy _at_ oss.ntt.co.jp NTT Open Source Software Center ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [HACKERS] RFC: changing autovacuum_naptime semantics

lly sounds more reasonable. We can use it to balance total I/O of workers in service time or maintenance time. It is not so difficult to achieve this by leveraging the share memory of autovacuum. Best Regards Galy Lee ---(end of broadcast)--- TIP 9:

Re: [HACKERS] RFC: changing autovacuum_naptime semantics

Alvaro Herrera wrote: > I don't have anything else as detailed as a "plan". If you have > suggestions, I'm all ears. Cool, thanks for the update. :) We also have some new ideas on the improvement of autovacuum now. I will raise it up later. > Now regarding your restartable vacuum work. > Does

Re: [HACKERS] RFC: changing autovacuum_naptime semantics

autovacuum improvement for 8.4? Thanks, Galy Lee lee.galy _at_ ntt.oss.co.jp NTT Open Source Software Center ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joini

[HACKERS] Restartable VACUUM design overview version 2

for it now. But I hope the *restartable VACUUM feature* can be accepted for 8.3. Hope your comments and suggestions. Best Regards Galy Lee NTT Open Source Software Center ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project b

Re: [HACKERS] Resumable vacuum proposal and design overview

Simon Riggs wrote: > Galy, please hear that people like your idea and understand your use > case, but just don't like all of the proposal, just the main thrust of > it. The usual way is that > (people that agree + amount of your exact idea remaining) = 100% Thank you. I am glad to hear that. :)

Re: [HACKERS] Resumable vacuum proposal and design overview

cation for me. :) Regards, -- Galy Lee lee.galy _at_ oss.ntt.co.jp NTT Open Source Software Center ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

Re: [HACKERS] Resumable vacuum proposal and design overview

runcate_heap, it takes AccessExclusiveLock for a long time, that is problematic. Except we change such kinds of mechanism to ensure that there is no problem to run vacuum on the same table for several days, we can not say we don’t need to stop in a half way. Best Regards, -- Galy Lee <[EMAIL PR

Re: [HACKERS] autovacuum next steps, take 2

Tom Lane wrote: > Saving the array is > expensive both in runtime and code complexity, and I don't believe we > can trust it later --- at least not without even more expensive-and- > complex measures, such as WAL-logging every such save :-( I don’t understand well the things you are worrying about

Re: [HACKERS] Resumable vacuum proposal and design overview

Tom Lane wrote: >One problem with it is that a too-small target would result in vacuum >proceeding to scan indexes after having accumulated only a few dead >tuples, resulting in increases (potentially enormous ones) in the total >work needed to vacuum the table completely. Yeah. This is also my bi

Re: [HACKERS] Resumable vacuum proposal and design overview

Simon Riggs wrote: >>old dead tuple list. If the system manages the dead tuple list we may >>need to keep such files around for long periods, which doesn't sound >>great either. The system manages such files. The files are kept in location like $PGDATA/pg_vacuum. They are removed when CLUSTER, DR

[HACKERS] Resumable vacuum proposal and design overview

sorry this late proposal, but I hope it can go into 8.3. Welcome your comments and ideas. Best Regards Galy Lee ([EMAIL PROTECTED]) NTT Open Source Software Center ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donat

Re: [HACKERS] autovacuum next steps

also merge the free space information into FSM. We are working on this feature now. I will propose it latter to discuss with you. Best Regards Galy Lee -- NTT Open Source Software Center ---(end of broadcast)--- TIP 7: You can help suppor

Re: [HACKERS] [PERFORM] how to plan for vacuum?

Jim C. Nasby wrote: On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote: Jim C. Nasby wrote: I'll generally start with a cost delay of 20ms and adjust based on IO utilization. I've been considering set a default autovacuum cost delay to 10ms; does this sound reasonable? The pro

Re: [HACKERS] Deadline-Based Vacuum Delay

e interval of two vacuums? It seems that there is not easy to tune the delay time of vacuum correctly. Best Regards -- Galy Lee NTT Open Source Software Center ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an a

[HACKERS] Deadline-Based Vacuum Delay

ect on the producing system outside the maintenance window. Any ideas or comments? Best Regards, -- Galy Lee NTT Open Source Software Center ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to c