Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Date
Msg-id CA+TgmoYNS3SNjk5DuFZw4E2POSpk+FjmtVqDu9-tOttS1FPgyw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Mar 21, 2017 at 6:56 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Hmm, that test case isn't all that synthetic.  It's just a single
>> column bulk update, which isn't anything all that crazy, and 5-10%
>> isn't nothing.
>>
>> I'm kinda surprised it made that much difference, though.
>>
>
> I think it is because heap_getattr() is not that cheap.  We have
> noticed the similar problem during development of scan key push down
> work [1].

Yeah.  So what's the deal with this?  Is somebody working on figuring
out a different approach that would reduce this overhead?  Are we
going to defer WARM to v11?  Or is the intent to just ignore the 5-10%
slowdown on a single column update and commit everything anyway?  (A
strong -1 on that course of action from me.)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: [HACKERS] Create replication slot in pg_basebackup if requestedand not yet present
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] WIP: [[Parallel] Shared] Hash