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. 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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org