Subject: Re: Patch: Write Amplification Reduction Method (WARM)
To: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>
References: <20170308193038.rl4oe27hb4u4zhx4@alvherre.pgsql>
 <CA+Tgmoa7oVYTkDEAzZz2Zw2mwz49orRWV4vYPr6EZ2MP7cioRQ@mail.gmail.com>
 <CAA4eK1JeAp3g0-X8X0U87UW3YjNKG3qxR-0-xCTUY=mxT4aOag@mail.gmail.com>
 <CA+TgmoYNS3SNjk5DuFZw4E2POSpk+FjmtVqDu9-tOttS1FPgyw@mail.gmail.com>
 <CABOikdOdvqJXPATNqmyJMMpYHesQuZm-Y4Q9O033pOwoAyrOjA@mail.gmail.com>
 <CA+TgmobKTAN1m8qiZJ+w6L6Kw9CfHrSevhwnrfVPN3KxA6=4KQ@mail.gmail.com>
 <20170321164949.GA16918@momjian.us>
 <CA+TgmoaSBif2Zr2oQpGgUy5JiVTfhMnA+t50E81rPEyHtbPLog@mail.gmail.com>
 <CAH2-WznXeppsohs02-SQ+C8oT80WC3AKtAxXXKTgLhQaVQBnSw@mail.gmail.com>
 <CA+Tgmob1SJj3Km3eKu2UHxaekqdQsJ8kqbLWMpVwO8=fXMyqPA@mail.gmail.com>
 <20170321171900.GC16918@momjian.us>
Cc: Peter Geoghegan <pg@bowt.ie>, Pavan Deolasee <pavan.deolasee@gmail.com>,
 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>
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Message-ID: <12c3d28b-7144-c17a-4557-bb0ae79aecd0@2ndquadrant.com>
Date: Tue, 21 Mar 2017 19:05:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170321171900.GC16918@momjian.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 21/03/17 18:19, Bruce Momjian wrote:
> On Tue, Mar 21, 2017 at 01:14:00PM -0400, Robert Haas wrote:
>> On Tue, Mar 21, 2017 at 1:08 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>>> On Tue, Mar 21, 2017 at 10:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> I think that's a good question.  I previously expressed similar
>>>> concerns.  On the one hand, it's hard to ignore the fact that, in the
>>>> cases where this wins, it already buys us a lot of performance
>>>> improvement.  On the other hand, as you say (and as I said), it eats
>>>> up a lot of bits, and that limits what we can do in the future.  On
>>>> the one hand, there is a saying that a bird in the hand is worth two
>>>> in the bush.  On the other hand, there is also a saying that one
>>>> should not paint oneself into the corner.
>>>
>>> Are we really saying that there can be no incompatible change to the
>>> on-disk representation for the rest of eternity? I can see why that's
>>> something to avoid indefinitely, but I wouldn't like to rule it out.
>>
>> Well, I don't want to rule it out either, but if we do a release to
>> which you can't pg_upgrade, it's going to be really painful for a lot
>> of users.  Many users can't realistically upgrade using pg_dump, ever.
>> So they'll be stuck on the release before the one that breaks
>> compatibility for a very long time.
> 
> Right.  If we weren't setting tuple and tid bits we could imrpove it
> easily in PG 11, but if we use them for a single-change WARM chain for
> PG 10, we might need bits that are not available to improve it later.
> 

I thought there is still couple of bits available.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers