From: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Chris Browne <cbbrowne(at)acm(dot)org> |
Subject: | Re: plans for bitmap indexes? |
Date: | 2004-10-20 02:15:54 |
Message-ID: | mjqy8i2jfs5.fsf@drones.CS.Berkeley.EDU |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
Tom> One huge advantage is that the actual heap visiting becomes
Tom> efficient, eg you never visit the same page more than once.
Tom> (What you lose is the ability to retrieve data in index
Tom> order, so this isn't a replacement for existing indexscan
Tom> methods, just another plan type to consider.)
Even without bitmap indexes, without trying to use multiple indexes
etc. this (visiting a page only once) is useful.
In other words, I'd like to see the indexscan broken up into: (1) an
operator that returns a list of TIDs, (2) Sort the TIDs and (3) an
operator that fetches heap tuples from the sorted TID list.
Of course the resulting data from the heap will be out of order but
that often times is less important than unnecessarily visiting (and
possibly even re-fetching from disk) the same heap page twice for a
given index scan.
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-10-20 02:48:21 | Re: Time off |
Previous Message | Philip Warner | 2004-10-20 01:06:18 | Re: Using ALTER TABLESPACE in pg_dump |