Re: the big picture for index-only scans

On Tue, May 10, 2011 at 8:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, May 9, 2011 at 10:36 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> 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.
>>
>> hm, what are the implications for tuple hint bits, short and long
>> term?  I'm particularly interested if you think any hint bit i/o
>> mitigation strategies are worth pursuing.
>
> Well, I don't really want to let this thread on my project get
> hijacked to talk about your project (not that I haven't been guilty of
> that myself!)

no, that wasn't my intent at all, except in the sense of wondering if
a crash-safe visibility map provides a route of displacing a lot of
hint bit i/o and by extension, making alternative approaches of doing
that, including mine, a lot less useful. that's a good thing.

meaning: since the vis map approach is going to be a fairly large win
over the classic approach to checking visibility in so many scenarios,
maybe the real long term goal should be just being as aggressive as
possible in terms of making sure it's set properly, and just give up
and be a bit more brute forcey when it's not set. it's a fair
question. that's a pretty broad statement, but that's what I'm
thinking about.

merlin