From: | Lars Helge Øverland <larshelge(at)gmail(dot)com> |
---|---|
To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Index only scan |
Date: | 2012-10-11 10:52:32 |
Message-ID: | CAD_DPKxD1rzr37=M3vhjJwDtWqe4MN68jyfCPXpejHBGW27iwA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks all for the help and insights. I will continue to read up on
the details of partitioning and pgpool.
best regards,
Lars
On Thu, Oct 11, 2012 at 2:47 AM, Gavin Flower
<GavinFlower(at)archidevsys(dot)co(dot)nz> wrote:
> On 11/10/12 12:41, Tom Lane wrote:
>>
>> 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
>
> Thanks for the correction!
>
> Cheers,
> Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Harding | 2012-10-11 14:52:56 | OpenSCG 9.0.10 package |
Previous Message | Vineet Deodhar | 2012-10-11 09:44:50 | Re: moving from MySQL to pgsql |