From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: the big picture for index-only scans |
Date: | 2011-05-11 09:31:13 |
Message-ID: | BANLkTi=O+f51uFxZd=aMQydYBNVHy2xvuw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/5/11, Bruce Momjian <bruce(at)momjian(dot)us>:
> FYI, because the visibility map is only one _bit_ per page, it is 8000 *
> 8 or 64k times smaller than the heap, e.g. one 8k page covers 64MB of
> heap pages.
Actually, that would be "one 8kB block covers 512MB of heap": 1 block
of visibility map (8kB) = 64k visibility bits = covers 64k blocks =
covers 512MB of heap. The cost of keeping the visibility map in cache
is therefore totally negligible, only the cost of WAL logging changes
to it is of interest.
> This is important because we rely on this compactness in hope that
> the WAL logging of this information will not be burdensome.
The size of on entry in the map (1 bit) is not very related to the WAL
overhead required per change of such a bit (i.e., the log record for a
1 bit change will certainly be way more than 1 bit).
Nicolas
--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2011-05-11 09:32:17 | Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays |
Previous Message | Szymon Guz | 2011-05-11 09:30:51 | Re: potential bug in trigger with boolean params |