Re: UNDO and in-place update

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UNDO and in-place update
Date: 2016-11-24 07:32:47
Message-ID: 0A3221C70F24FB45833433255569204D1F65AA15@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

IMHO, overall, there should be pros and cons of the current approach and the new UNDo one (like Oracle?), depending on the workload. Under update-heavy workload, the UNDO method may be better. OTOH, under the mostly-INSERT workload (like data warehouse?), the current method will be better because it writes no log for UNDO.

Furthermore, it maybe the best to be able to switch the method for each table and/or tablespace. For example, in pgbench, history table uses the current method,
and other tables use the UNDO method. Is it time to introduce a pluggable storage system?

Because PostgreSQL is a follower in the UNDO approach, I think it will be better to study other DBMSs well (Oracle and MySQL?). That includes not only their manuals, but also whitepapers and books. Especially, I expect good books to give deep knowledge on performance tuning and troubleshooting, from which we will be able to know the cons that Oracle's materials don't state.

Regards
Takayuki Tsunakawa

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2016-11-24 07:35:38 Re: UNDO and in-place update
Previous Message Etsuro Fujita 2016-11-24 07:30:24 Re: Push down more full joins in postgres_fdw