> Ühel kenal päeval, R, 2006-06-23 kell 17:27, kirjutas Bruce Momjian:
>> Jonah H. Harris wrote:
>> > On 6/23/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> > > 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.
>> >
>> > I'm being totally objective.  I don't think we should abandon
>> > PostgreSQL's overall design at all, because we do perform INSERTs and
>> > DELETEs much better than most systems.  However, I've looked at many
>> > systems and how they implement UPDATE so that it is a scalable
>> > operation.  Sure, there are costs and benefits to each implementation,
>> > but I think we have some pretty brilliant people in this community and
>> > can come up with an elegant design for scalable UPDATEs.
>> I think the UPDATE case is similar to the bitmap index scan or perhaps
>> bitmap indexes on disk --- there are cases we know can not be handled
>> well by our existing code, so we have added (or might add) these
>> features to try to address those difficult cases.
> Not really. Bitmap index scan and bitmap index are both new additions
> working well with existing framework.
> While the problem of slowdown on frequent updates is real, the suggested
> fix is just plain wrong, as it is based on someones faulty assumption on
> how index lookup works, and very much simplified view of how different
> parts of the system work to implement MVCC.

Yes, the suggestion was based on MVCC concepts, not a particular
> The original fix he "suggests" was to that imagined behaviour and thus
> ignored all the real problems of such change.

The original suggestion, was nothing more than a hypothetical for the
purpose of discussion.

The problem was the steady degradation of performance on frequent updates.
That was the point of discussion.  I brought up "one possible way" to
start a "brain storm." The discussion then morphed into critisizing the
example and not addressing the problem.

Anyway, I think some decent discussion about the problem did happen, and
that is good.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to