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

  Bruce Momjian   [EMAIL PROTECTED]

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to