From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Composite Datums containing toasted fields are a bad idea(?) |
Date: | 2014-04-21 16:36:17 |
Message-ID: | 20140421163616.GE25695@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure wrote:
> On Mon, Apr 21, 2014 at 10:40 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > And too bad that infomask bits are so scarce :(. We really need to
> > reclaim HEAP_MOVED_OFF and HEAP_MOVED_IN.
>
> The only consequence of that is losing support for in-place update for
> pre-9.0 (of which the only supported version is 8.4). I figure it's
> also pretty reasonable to drop support for IPU for out of support
> versions for new versions going forward. That would recover the bits
> and yield some nice cleanups in tqual.c.
There's no way to be sure that the bits have been removed from tables
that were upgraded from a 8.4 server to a 9.0 server and from there to a
newer server. We'd need some way to catalogue which tables have been
cleaned prior to an upgrade to a release that no longer accepts those
bits; pg_upgrade would then say "table xyz needs to be vacuumed before
the upgrade" in check mode, or something like that.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-04-21 16:38:59 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |
Previous Message | Stephen Frost | 2014-04-21 16:34:07 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |