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

From Petr Jelinek
Subject Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Date
Msg-id 6db5bac9-0b05-f349-a109-f3e2c5bf1581@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 21/03/17 18:14, 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.
> 

This is why I like the idea of pluggable storage, if we ever get that it
would buy us ability to implement completely different heap format
without breaking pg_upgrade.

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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] GUC for cleanup indexes threshold.