Re: UNDO and in-place update
От | Robert Haas |
---|---|
Тема | Re: UNDO and in-place update |
Дата | |
Msg-id | CA+TgmoYBgvJE6SchMbS7v1X2SLC1=BipquRs0P47d8zpmtyRvg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: UNDO and in-place update (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: UNDO and in-place update
|
Список | pgsql-hackers |
On Thu, Nov 24, 2016 at 6:20 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> I think that the whole emphasis on whether and to what degree this is >> like Oracle is somewhat misplaced. I would look at it a different >> way. We've talked many times over the years about how PostgreSQL is >> optimized for aborts. Everybody that I've heard comment on that issue >> thinks that is a bad thing. > > > again this depends on usage - when you have a possibility to run VACUUM, > then this strategy is better. > > The fast aborts is one pretty good feature for stable usage. > > Isn't possible to use UNDO log (or something similar) for VACUUM? ROLLBACK > should be fast, but > VACUUM can do more work? I think that in this design we wouldn't use VACUUM at all. However, if what you are saying is that we should try to make aborts near-instantaneous by pushing UNDO actions into the background, I agree entirely. InnoDB already does that, IIUC. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: