Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I think at some point we have to admit that _polling_ the tables, which > > is what autovacuum does, just isn't going to work well, no matter how > > much it is tweeked, and another approach should be considered for > > certain workload cases. > > Autovacuum polls in its current, first-generation implementation; > what I said upthread was it needs to be smarter than that. I am not > sure how you get from that to the conclusion that the very next step > is to abandon the vacuuming approach altogether.
I am not ready to abandon autovacuum, but as I stated later the UPDATE with no key change case is common enought that it could be handled better without involving autovacuum and its limitations. As I remember, most databases have problem with DELETE/INSERT cycles, but we seem to be hit by UPDATE performance more than most, and more than is wise. > What I see in this discussion is a huge amount of "the grass must be > greener on the other side" syndrome, and hardly any recognition that > every technique has its downsides and complications. Furthermore, > I do not believe that this project has the ability to support multiple > fundamental storage models, as a number of people seem to be blithely > suggesting. We're having a hard enough time debugging and optimizing > *one* storage model. I think the correct path forward is to stick with > the same basic storage model and vacuuming concept, and address the > known performance issues with better-optimized vacuuming. No, it will > never be perfect for every scenario, but we can certainly make it much > better than it is now, without risking killing the project by > introducing undebuggable, unmaintainable complexity. Well, are you suggesting we just stop improving the database? I am sure not. But, your suggestion is that we can't do better without incurring more complexity (true), and that complexity will not be worth it. I don't agree with that until I see some proposals, and shutting down discussion because they will add complexity or are fruitless seems unwise. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
