<p><font size="2">A hybrid scan approach combined with this idea would fit nicely - provide results for tids that are
directlyvisible and set a bit in a bitmap for those that need recheck and extend recheck to take a bitmap (wait - it
alreadydoes :-)<br /><br /> - Luke<br /><br /> Msg is shrt cuz m on ma treo<br /><br /> -----Original Message-----<br
/>From: Gregory Stark [<a href="mailto:stark@enterprisedb.com">mailto:stark@enterprisedb.com</a>]<br /> Sent:
Wednesday,August 15, 2007 02:58 PM Eastern Standard Time<br /> To: Bruce Momjian<br /> Cc:
PostgreSQL-development<br/> Subject: Re: [HACKERS] Another idea for index-only scans<br /><br /> "Bruce Momjian"
<bruce@momjian.us>writes:<br /><br /> > I have added another idea for index-only scans to the TODO list:<br />
><br/> >> A third idea would be for a heap scan to check if all rows are visible<br /> >> and if so
seta per-table flag which can be checked by index scans.<br /> >> Any change to the table would have to clear
theflag. To detect<br /> >> changes during the heap scan a counter could be set at the start and<br />
>> checked at the end --- if it is the same, the table has not been<br /> >> modified --- any table
changewould increment the counter.<br /><br /> I think I would prefer to address this in the same infrastructure as
the<br/> dead-space-map. That way you're not dependent on having no updates happening<br /> on the table at all. Any
tupleson pages which contain no in-doubt tuples<br /> could have their visibility check skipped but when you come
acrossa tuple on<br /> a page which has been modified since the last vacuum then you have to check<br /> the
visibility.<br/><br /> --<br /> Gregory Stark<br /> EnterpriseDB <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/><br /> ---------------------------(end of
broadcast)---------------------------<br/> TIP 4: Have you searched our list archives?<br /><br /> <a
href="http://archives.postgresql.org">http://archives.postgresql.org</a><br/></font>
