Re: vacuum, performance, and MVCC - Mailing list pgsql-hackers

On 6/23/2006 9:56 PM, mark@mark.mielke.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@Yahoo.com #