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
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 |