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!
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 |