Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: the big picture for index-only scans
Date
Msg-id BANLkTi=JQbaxrneVB0SoEPvByHU1PscZTw@mail.gmail.com
Whole thread Raw
In response to Re: the big picture for index-only scans  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, May 11, 2011 at 2:34 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> So, what do we need in order to find our way to index-only scans?
>>
>> 1. The visibility map needs to be crash-safe.  The basic idea of
>> index-only scans is that, instead of checking the heap to find out
>> whether each tuple is visible, we first check the visibility map.  If
>> the visibility map bit is set, then we know all tuples on the page are
>> visible to all transactions, and therefore the tuple of interest is
>> visible to our transaction.  Assuming that a significant number of
>> visibility map bits are set, this should enable us to avoid a fair
>> amount of I/O, especially on large tables, because the visibility map
>> is roughly 8000 times smaller than the heap, and therefore far more
>> practical to keep in cache.  However, before we can rely on the
>
> 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.  This is important because we rely on this compactness in
> hope that the WAL logging of this information will not be burdensome.

We would need to issue one WAL record per bit, not per page.

I'm concerned about the path length added by VM visits and the
potential contention that concentration of information will bring.

Those aren't things to be dismissed without calculation and analysis.
There might not be an issue there, but its worth checking.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: the big picture for index-only scans
Next
From: Szymon Guz
Date:
Subject: potential bug in trigger with boolean params