| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Subject: | Re: Freeze avoidance of very large table. |
| Date: | 2015-04-23 16:31:32 |
| Message-ID: | 55391E64.1070103@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/23/15 11:06 AM, Petr Jelinek wrote:
> On 23/04/15 17:45, Bruce Momjian wrote:
>> On Thu, Apr 23, 2015 at 09:45:38AM -0400, Robert Haas wrote:
>> Agreed, no extra file, and the same write volume as currently. It would
>> also match pg_clog, which uses two bits per transaction --- maybe we can
>> reuse some of that code.
>>
>
> Yeah, this approach seems promising. We probably can't reuse code from
> clog because the usage pattern is different (key for clog is xid, while
> for visibility/freeze map ctid is used). But visibility map storage
> layer is pretty simple so it should be easy to extend it for this use.
Actually, there may be some bit manipulation functions we could reuse;
things like efficiently counting how many things in a byte are set.
Probably doesn't make sense to fully refactor it, but at least CLOG is a
good source for cut/paste/whack.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2015-04-23 16:42:24 | Re: Reducing tuple overhead |
| Previous Message | Andres Freund | 2015-04-23 16:24:29 | Reducing tuple overhead |