Re: Index-only scans

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
>

In response to

Responses

Browse pgsql-hackers by date

  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