On 6/23/2006 9:56 PM, [EMAIL PROTECTED] 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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
