From: | Mischa Sandberg <mischa(dot)sandberg(at)sophos(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index-only scans |
Date: | 2009-07-13 22:38:36 |
Message-ID: | CB0F73E165CFFA4496D12161D835562CF876AB6C@US-COL-EXCHMBX1.green.sophos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Does PG have an intermediate execution node to sort/batch index entries (heap tuple ptrs) by heap page prior to lookup? Something mssql does ...
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> Sent: Monday, July 13, 2009 6:38 AM
> To: Heikki Linnakangas
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Index-only scans
>
> 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.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-hackers mailing list
> (pgsql-hackers(at)postgresql(dot)org) To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-13 22:40:00 | Re: Alpha release process |
Previous Message | Bruce Momjian | 2009-07-13 22:38:13 | Re: [GENERAL] large object does not exist after pg_migrator |