Re: UNDO and in-place update
От | Pavel Stehule |
---|---|
Тема | Re: UNDO and in-place update |
Дата | |
Msg-id | CAFj8pRAgHSh565+nvou9XRnfBSa7y7TD8+YZ1UwxPpNoT6CGKw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: UNDO and in-place update (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
2016-11-25 1:44 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
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.
ok, it can be another process - that can be more aggressive and less limited than vacuum.
Regards
Pavel
В списке pgsql-hackers по дате отправления: