From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Physical append-only tables |
Date: | 2016-11-14 01:35:51 |
Message-ID: | 20161114013551.tjj5yz5okggsm4p2@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
> But then consider the same table. Except rows are typically updated once or
> twice when they are new, and *then* go read only. And we also have a
> process that at some point deletes *some* old rows (but not all - in fact,
> only a small portion).
>
> In this case, the next INSERT once VACUUM has run is likely to stick a
> "new" row somewhere very "far back" in the table, since there is now free
> space there. This more or less completely ruins the BRIN index usability,
> as the "old" blocks will now contain a single row from a "new" series.
Yeah. When we initially discussed BRIN, there was a mention of allowing
a BRIN index to guide new tuple location -- something like
auto-clustering, if you will. We haven't discussed the exact details
but I think something along those lines is worth considering.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2016-11-14 02:02:07 | Re: Patch: Implement failover on libpq connect level. |
Previous Message | Tomas Vondra | 2016-11-14 00:20:00 | Re: PATCH: two slab-like memory allocators |