Re: Patch: Write Amplification Reduction Method (WARM)
Pavan Deolasee <pavan.deolasee@gmail.com>
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Jaime Casanova <jaime.casanova@2ndquadrant.com>, Haribabu Kommi <kommi.haribabu@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-28T17:26:27Z
Lists: pgsql-hackers
On Tue, Mar 28, 2017 at 8:34 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Mar 27, 2017 at 10:25 PM, Pavan Deolasee > <pavan.deolasee@gmail.com> wrote: > > On Tue, Mar 28, 2017 at 1:59 AM, Robert Haas <robertmhaas@gmail.com> > wrote: > >> On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee > >> <pavan.deolasee@gmail.com> wrote: > >> > It's quite hard to say that until we see many more benchmarks. As > author > >> > of > >> > the patch, I might have got repetitive with my benchmarks. But I've > seen > >> > over 50% improvement in TPS even without chain conversion (6 indexes > on > >> > a 12 > >> > column table test). > >> > >> This seems quite mystifying. What can account for such a large > >> performance difference in such a pessimal scenario? It seems to me > >> that without chain conversion, WARM can only apply to each row once > >> and therefore no sustained performance improvement should be possible > >> -- unless rows are regularly being moved to new blocks, in which case > >> those updates would "reset" the ability to again perform an update. > >> However, one would hope that most updates get done within a single > >> block, so that the row-moves-to-new-block case wouldn't happen very > >> often. > > > > I think you're confusing between update chains that stay within a block > vs > > HOT/WARM chains. Even when the entire update chain stays within a block, > it > > can be made up of multiple HOT/WARM chains and each of these chains offer > > ability to do one WARM update. So even without chain conversion, every > > alternate update will be a WARM update. So the gains are perpetual. > > You're right, I had overlooked that. But then I'm confused: how does > the chain conversion stuff help as much as it does? You said that you > got a 50% improvement from WARM, because we got to skip half the index > updates. But then you said with chain conversion you got an > improvement of more like 100%. However, I would think that on this > workload, chain conversion shouldn't save much. If you're sweeping > through the database constantly performing updates, the updates ought > to be a lot more frequent than the vacuums. > > No? These tests were done on a very large table of 80M rows. The table itself was wide with 15 columns and a few indexes. So in a 8hr test, master could do only 55M updates where as WARM did 105M updates. There were 4 autovacuum cycles in both these runs. So while there were many updates, I am sure autovacuum must have helped to increase the percentage of WARM updates (from ~50% after steady state to ~67% after steady state). Also I said more than 50%, but it was probably close to 65%. Unfortunately these tests were done on different hardware, with different settings and even slightly different scale factors. So they may not be exactly comparable. But there is no doubt chain conversion will help to some extent. I'll repeat the benchmark with chain conversion turned off and report the exact difference. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Implement SortSupport for macaddr data type
- f90d23d0c518 10.0 cited
-
Simplify check of modified attributes in heap_update
- 2fd8685e7fd9 10.0 landed
-
Remove direct uses of ItemPointer.{ip_blkid,ip_posid}
- ce96ce60ca22 10.0 landed
-
Fix CatalogTupleInsert/Update abstraction for case of shared indstate.
- aedd554f84bb 10.0 landed
-
Provide CatalogTupleDelete() as a wrapper around simple_heap_delete().
- ab02896510e2 10.0 landed
-
Band-aid fix for incorrect use of view options as StdRdOptions.
- e3e66d8a9813 10.0 cited
-
Update visibility map in the second phase of vacuum.
- fdf9e21196a6 9.3.0 cited
-
Avoid having two copies of the HOT-chain search logic.
- 4da99ea4231e 9.2.0 cited
-
Postgres95 1.01 Distribution - Virgin Sources
- d31084e9d111 7.1.1 cited