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  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Random PGDLLIMPORTing
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: patch: function xmltable