| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: An idle thought |
| Date: | 2010-03-18 21:07:00 |
| Message-ID: | 1268946420.4053.531.camel@monkey-cat.sm.truviso.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote:
> The VM is (a) not compressed and (b) not correctness-critical.
> Wrong bit values don't do any serious damage.
The VM cause wrong results if a bit is set that's not supposed to be --
right? Am I missing something? How does a seq scan skip visibility
checks and still produce right results, if it doesn't rely on the bit?
The visibility map would obviously not be very useful if visibility
information was randomly distributed among tuples. Whether that
qualifies as "compression" or not was not my primary point. The point is
that it may be possible to use some structure that is significantly
smaller than holding xmin/xmax for every tuple in the heap, and at the
same time may be acceptably fast to update.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Hunsaker | 2010-03-18 21:11:45 | Re: An idle thought |
| Previous Message | Tom Lane | 2010-03-18 20:50:12 | Re: An idle thought |