Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
От | Boszormenyi Zoltan |
---|---|
Тема | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c |
Дата | |
Msg-id | 4AA16407.8050605@cybertec.at обсуждение исходный текст |
Ответ на | Re: Eliminating VACUUM FULL WAS: remove flatfiles.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane írta: > Josh Berkus <josh@agliodbs.com> writes: > >>>> I have a client who uses temp tables heavily, hundreds of thousands of >>>> creates >>>> and drops per day. They also have long running queries. The only >>>> thing that >>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs >>>> a few times a day. With >>>> > > >> Actually, this is a good point ... if we dropped VACUUM FULL, we'd need >> to also be able to call CLUSTER (or VACUUM REWRITE) on the system catalogs. >> > > I don't think I believe the claim above that vacuum full is actually > necessary. Reasonably aggressive regular vacuuming ought to do it. > How about setting a non-100% fillfactor on catalog tables? Maybe by default? That would also avoid most of the bloat, wouldn't it? > We used to have a bug that caused row deletions during backend shutdown > to not get reported to the stats collector; which had the effect that > dead catalog entries for temp tables didn't get counted, and so autovac > didn't hit the catalogs often enough, and so you'd get bloat in exactly > this scenario. I suspect the claim that manual vacuum full is necessary > is based on obsolete experience from before that bug got stomped. > It's hardly an ideal solution anyway given what an exclusive lock on > pg_class will do to the rest of the system --- and a cluster-like > cleanup won't be any better about that. > > regards, tom lane > > -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: