Re: vacuum, performance, and MVCC

On 6/23/2006 9:56 PM, mark(at)mark(dot)mielke(dot)cc wrote:

> On Fri, Jun 23, 2006 at 03:08:34PM -0400, Bruce Momjian wrote:
>> Tom Lane wrote:
>> > ...
>> > 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.
>
> It sounds like everybody agrees that things need to be fixed, and genuinely
> motivated people are trying to offer what they have to the table.

One singe core team member responds vaguely in a way, you feel being
supportive of your case, and you conclude that "everybody agrees"?
Sorry, x'use me?

There are a couple of side effects on this "update in place" issue that
aren't even mentioned yet. Nobody with any significant in depth
knowledge of the Postgres non-overwriting storage engine concept seems
to suggest any move towards a storage system, that does updates in place
that require "undo" operations in case of a process/system failure.
You're ready to "fix" all those places to support the undo you need? You
must have a big table.

Jan

>
> Tom already has enough on his plate, as do most others here - so unless
> a competent champion can take up the challenge, discussion is all we have.
>
> I'm not liking the "we should do it this way," "no, we should do it that."
> My read of the situation is that both may be useful, and that both should
> be pursued. But one set of people can't pursue both.
>
> Is any who is able, able to take up this challenge? Perhaps more than one,
> from both major directions? (vacuum on one side, and improved storage on
> the other) Somebody with the time and skill, who can work through the
> design discussions on one of the aspects?
>
> I want to contribute soon, and this is the sort of thing that interests me -
> but I still don't have time yet, and there would be no guarantee that I
> succeeded. Somebody else? :-)
>
> Cheers,
> mark
>

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #