From: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index-only scans |
Date: | 2010-01-09 08:05:03 |
Message-ID: | 9362e74e1001090005j71aef519u7062ba6b3dd25277@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Heikki,
I was recollecting our conversation that, if the index-only quals
were implemented through indexes by storing snapshots, broken data-types may
not be supported. I feel this problem might exist, if we go on design a
IOT(Index Organized Tables) / Clustered Indexes. IOT is again a index which
stores snapshot info together with it.
So are we not going to have this feature ever in PG? What is our
stand in that case? I am asking this because i have an IOT implementation on
PG 8.2.
Thanks,
Gokul
On Tue, Jul 14, 2009 at 2:08 PM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Simon Riggs wrote:
> > On Mon, 2009-07-13 at 10:16 +0300, Heikki Linnakangas wrote:
> >
> >> Implementing index-only scans requires a few changes:
> >
> > I would like to see a clear exposition of the use cases and an an
> > analysis of the costs and benefits of doing this. It sounds cool, but I
> > want to know it is cool before we spend time solving all of the juicy
> > problems.
>
> BTW, there's another trick that I'm *not* going to implement yet, which
> is to allow joins using data from indexes only, and fetching the rest of
> the columns after the join. For example:
>
> CREATE TABLE a (aid integer PRIMARY KEY, adata text);
> CREATE TABLE b (bid integer PRIMARY KEY, bdata text);
>
> SELECT aid, adata, bid, bdata FROM a, b WHERE aid = bid;
>
> If the join is very selective, IOW there's only a few matching rows, it
> is a lot more efficient to perform the join first using just the
> indexes, and fetch adata and bdata columns and check visibility for the
> matching rows only.
>
> You can get pretty close by clustering the tables, but the wider the
> tables the bigger the difference.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> 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 | Markus Wanner | 2010-01-09 09:12:44 | Re: Serializable Isolation without blocking |
Previous Message | Heikki Linnakangas | 2010-01-09 07:25:31 | Re: Streaming replication status |