From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: Index-only scans |
Date: | 2009-07-14 12:41:28 |
Message-ID: | 200907141541.28715.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday 13 July 2009 16:38:18 Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > Even if we don't solve the visibility
> > map problem, just allowing the executor to evaluate quals that are not
> > directly indexable using data from the index, would be useful. For
> > example, "SELECT * FROM foo WHERE textcol LIKE '%bar%', and you have a
> > b-tree index on textcol, the planner could choose a full-index-scan,
> > apply the '%bar%' filter on the index tuples, and only fetch those heap
> > tuples that match that qual.
>
> Interesting, I had not considered that. You are using the index as a
> single-column table that can be scanned more quickly than the heap.
On slightly bizarre application of this could be that you create a poor man's
column storage by creating heap "indexes" on tables. These would just be
narrower copies of the original heap, but allow faster fetching. This might
actually be useful for data types that don't support btree indexing.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-14 13:46:51 | Re: [PATCH] "could not reattach to shared memory" on Windows |
Previous Message | Tsutomu Yamada | 2009-07-14 10:22:42 | [PATCH] "could not reattach to shared memory" on Windows |