Re: Index-only scans

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index-only scans
Date: 2009-07-15 00:50:10
Message-ID: 407d949e0907141750t527843fak5e895c4f0fb9cf4a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 15, 2009 at 1:21 AM, Ron Mayer<rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> Really?  I'd have thought that index is similar to materializing
> these views:
>  create view a_b as select aid,bid from manytomany order by aid,bid;
>  create view b_a as select bid,aid from manytomany order by bid,aid;
> Or perhaps
>  create view a_b as select aid,array_agg(bid) from manytomany group by aid;

How do any of these views help you answer a query like "select aid
from manytomany where bid in (subquery)"?

The last one could help you answer the dual of that but not without
rewriting the query quite heavily to use array operations. The first
two I'm puzzled how they're useful at all since unless you add indexes
to the materialized views they'll just contain a complete copy of the
original table -- the most they could help with is avoiding a sort but
they'll never be updatable so they'll rarely actually be usable.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2009-07-15 00:55:35 Re: CommitFest 2009-07 is Now Closed
Previous Message Jeremy Kerr 2009-07-15 00:42:07 Re: [PATCH 1/2 v3] [libpq] rework sigpipe-handling macros