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.
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 |