Re: Visibility map thoughts

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Visibility map thoughts
Date: 2007-11-06 20:04:29
Message-ID: 87r6j316pe.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> writes:

> For example, if there is a query like select count(1) from table. Then
> we can scan through all the index pages and the visibility map to get
> the count. Currently it goes for Full table scan. there should be
> something like full index scan, which should take care of it.

Huh, that does lead me to something we hadn't mentioned previously. If we kept
count of how many tuples were on each known-visible page then we could do a
full tables scan and still skip heap page fetches if we don't need any columns
(ie, for select count(*)).

I guess it's not terribly useful for anything other than select count(*)
though. But it would be nice. It would not suffer from the concurrency issues
that caching a single count would have because only vacuum (and page pruning)
would every update the count. Normal updates/delete/inserts would only have to
clear the bit and only if the page was marked as having the bit set.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-11-06 20:13:19 Re: Visibility map thoughts
Previous Message Tom Lane 2007-11-06 19:42:23 EquivalenceClasses vs volatile functions