From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: An idle thought |
Date: | 2010-03-17 21:39:05 |
Message-ID: | 1268861945.4053.503.camel@monkey-cat.sm.truviso.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2010-03-17 at 17:20 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > There are all kinds of challenges there, but it might be worth thinking
> > about. Visibility information is highly compressible, and requires
> > constant maintenance (updates, deletes, freezing, etc.). It also might
> > make it possible to move to 64-bit xids, if we wanted to.
>
> If you want it to be cheaply updatable (or even cheaply readable),
> compression is not what you're going to do.
I didn't mean that we'd want to compress it to the absolute minimum
size. I had envisioned that it would be a simple scheme designed only to
eliminate long runs of identical visibility information (perhaps only
the frozen and always visible regions would be compressed).
The extra level of indirection would be slower, but if we freeze tuples
more aggressively (which would be much cheaper if we didn't have to go
to the heap), there might be a small number of tuples with interesting
visibility information at any particular time.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-03-17 21:39:34 | Re: Order of pg_stat_activity timestamp columns |
Previous Message | Kevin Grittner | 2010-03-17 21:36:27 | Re: Order of pg_stat_activity timestamp columns |