Re: vacuum, performance, and MVCC
От | Mark Woodward |
---|---|
Тема | Re: vacuum, performance, and MVCC |
Дата | |
Msg-id | 18313.24.91.171.78.1151327403.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: vacuum, performance, and MVCC (Hannu Krosing <hannu@skype.net>) |
Ответы |
Re: vacuum, performance, and MVCC
|
Список | pgsql-hackers |
> Ãhel kenal päeval, R, 2006-06-23 kell 17:27, kirjutas Bruce Momjian: >> Jonah H. Harris wrote: >> > On 6/23/06, Tom Lane <tgl@sss.pgh.pa.us> 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 implementation. > > 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.
В списке pgsql-hackers по дате отправления: