On 9 October 2011 18:38, Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote: > 2011/10/9 Pavel Stehule <pavel.stehule@xxxxxxxxx>: >> 2011/10/9 Tom Lane <tgl@xxxxxxxxxxxxx>: >>> Pavel Stehule <pavel.stehule@xxxxxxxxx> writes: >>>> 2011/10/9 Thom Brown <thom@xxxxxxxxx>: >>>>> On 9 October 2011 04:35, Pavel Stehule <pavel.stehule@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
