SEO
vBulletin Search Engine Optimization
| |||||||
![Re: [HACKERS] Aggressive freezing in lazy-vacuum](http://unixadmintalk.com/iconimages/f47/re-hackers-aggressive-freezing-lazy-vacuum_ltr.gif)
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-18-2008, 09:39 AM
| ||||
| ||||
 Re: [HACKERS] Aggressive freezing in lazy-vacuum ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: > This is a stand-alone patch for aggressive freezing. I'll propose > to use OldestXmin instead of FreezeLimit as the freeze threshold > in the circumstances below: I think it's a really bad idea to freeze that aggressively under any circumstances except being told to (ie, VACUUM FREEZE). When you freeze, you lose history information that might be needed later --- for forensic purposes if nothing else. You need to show a fairly amazing performance gain to justify that, and I don't think you can. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly      |
|
04-18-2008, 09:40 AM
| |||
| |||
| Re: [HACKERS] Aggressive freezing in lazy-vacuum Tom Lane wrote: > ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: >> This is a stand-alone patch for aggressive freezing. I'll propose >> to use OldestXmin instead of FreezeLimit as the freeze threshold >> in the circumstances below: > > I think it's a really bad idea to freeze that aggressively under any > circumstances except being told to (ie, VACUUM FREEZE). When you > freeze, you lose history information that might be needed later --- for > forensic purposes if nothing else. You need to show a fairly amazing > performance gain to justify that, and I don't think you can. There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit would be calculated as GetOldestXmin() - vacuum_freeze_limit The default for vacuum_freeze_limit would be MaxTransactionId/2, just as it is now. greetings, Florian Pflug ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
|
04-18-2008, 09:40 AM
| |||
| |||
| Re: [HACKERS] Aggressive freezing in lazy-vacuum Florian G. Pflug wrote: > There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit > would be calculated as > GetOldestXmin() - vacuum_freeze_limit We already have that. It's called vacuum_freeze_min_age, and the default is 100 million transactions. IIRC we added it late in the 8.2 release cycle when we changed the clog truncation point to depend on freeze limit. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate |
|
04-18-2008, 09:40 AM
| ||||
| ||||
| Re: [HACKERS] Aggressive freezing in lazy-vacuum Heikki Linnakangas wrote: > Florian G. Pflug wrote: >> There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit >> would be calculated as >> GetOldestXmin() - vacuum_freeze_limit > > We already have that. It's called vacuum_freeze_min_age, and the default > is 100 million transactions. > > IIRC we added it late in the 8.2 release cycle when we changed the clog > truncation point to depend on freeze limit. Ok, that explains why I didn't find it when I checked the source - I checked the 8.1 sources by accident ;-) Anyway, thanks for pointing that out ;-) greetings, Florian Pflug ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |
Linear Mode
