On 9 October 2011 18:38, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2011/10/9 Pavel Stehule <pavel.stehule@gmail.com>:
>> 2011/10/9 Tom Lane <tgl@sss.pgh.pa.us>:
>>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>> 2011/10/9 Thom Brown <thom@linux.com>:
>>>>> On 9 October 2011 04:35, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>>>> It has a sense - index only scan it is faster (and significantly
>>>>>> faster) on wider tables - or tables with strings where TOAST is not
>>>>>> active. Maybe there is a some issue because on thin tables is slower
>>>>>> (and I expect a should be faster everywhere).
>>>
>>>>> No, that's my point, I re-tested it on a table with just 2 int
>>>>> columns, and the results are roughly the same. I added all the
>>>>> columns to make it expensive to fetch the column being queried.
>>>
>>>> then I don't understand
>>>
>>> Are you sure you've remembered to vacuum the test table? I get results
>>> like yours (ie, no speed benefit for index-only scan) if the table
>>> doesn't have its visibility-map bits set.
>>
>> it should be - I didn't do VACUUM
>>
>
> yes, After VACUUM I got a significantly better times - index only scan
> is about 5-6x better
Something that I was expecting the planner to do with this patch,
which it doesn't, is pull in the index for queries like:
SELECT count(*) from my_table;
or
SELECT sum(indexed_column) from my_table;
I don't see why a non-partial index can't fulfill these queries. I
can only get index-only scans with WHERE conditions.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company