Re: questions about PG update performance

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: questions about PG update performance
Дата
Msg-id CAFjFpRensYCXMB72wahLfJkeL62=pnw=LgoV6aj=-O9ni+8eCw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: questions about PG update performance  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: questions about PG update performance
Список pgsql-hackers


On Mon, Oct 26, 2015 at 10:19 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов <karavelov@mail.bg> wrote:
>
>
> ----- Цитат от Kisung Kim (kskim@bitnine.co.kr), на 26.10.2015 в 04:36 -----
>
> > However, what I want to know is about the update performance difference
> > between PG and Oracle if there any.
> > The case I described is for exaggerating the difference between PG and
> > Oracle.
> >
> > I want to explain for our clients that PG's update performance is
> > comparable to Oracle's.
> >
>
> Oracle is also using MVCC but copies the old row in the rollback segment and
> rewrites the values in-place.

I think Oracle just copies the changed part of old row to rollback segment.
Also in Redo logs, it just writes the changed column value (both old and
new).  So for the case we are discussing in this thread (one changed
column out of 200 columns), Oracle will just write the old value of that
column in Redo and then in rollback segment, and write the new value
in Redo and then do the in-place update in heap row.


In that case, readers would pay the penalty for constructing the row. PostgreSQL will not incur the cost of reconstruction. Either writer or reader is bound to pay penalty. If the user's load is reader heavy it makes sense to use something like PG, else something like what is described above.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench gaussian/exponential docs improvements
Следующее
От: Victor Wagner
Дата:
Сообщение: Patch (3): Implement failover on libpq connect level.