From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Cc: | Lars Helge Øverland <larshelge(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Index only scan |
Date: | 2012-10-10 23:41:42 |
Message-ID: | 13440.1349912502@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> writes:
> On 11/10/12 01:03, Lars Helge verland wrote:
>> My question is: Would it be feasible and/or possible to implement
>> index only scans in a way that it could take advantage of several,
>> single-column indexes? For example, a query spanning columns a, b, c
>> could take advantage of 3 single-column indexes put on columns a, b,
>> c.
> Index only scans do use multiple indexes of single fields where
> appropriate. Here the planner determined it only needed to scan 2 of
> the 3 relevant single field indexes.
But your example isn't an index-only scan ... it's a plain old bitmap
scan, and so it does touch the heap.
The difficulty with what Lars proposes is that there's no way to scan
the different indexes "in sync" --- each one will be ordered according
to its own column order. In principle I guess we could read out the
index data and do a join using the ctid's, but it's far from clear that
such a thing would be worth the trouble.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-10-10 23:50:45 | Re: Planner chooses multi-column index in 9.2 when maybe it should not |
Previous Message | Ondrej Ivanič | 2012-10-10 23:36:20 | Re: Index only scan |