Re: Patch: Write Amplification Reduction Method (WARM)
David Steele <david@pgmasters.net>
From: David Steele <david@pgmasters.net>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 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-28T15:32:59Z
Lists: pgsql-hackers
Hi Pavan, On 3/28/17 11:04 AM, Robert Haas 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? It appears that a patch is required to address Amit's review. I have marked this as "Waiting for Author". Thanks, -- -David david@pgmasters.net
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