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 <p...@bowt.ie> wrote: >>> On Tue, Mar 21, 2017 at 10:04 AM, Robert Haas <robertmh...@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
