On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer <spam_eater@xxxxxxx> wrote: > Tom Lane wrote on 26.08.2012 16:31: > >> Thomas Kellerer <spam_eater@xxxxxxx> writes: >>> >>> I'm playing around with 9.2 beta4 and was looking into the new Index Only >>> Scan feature. >>> I was a bit surprised that a "count(*)" query does not use an index. >> >> >> Works for me. However, the cost estimate for that is heavily dependent >> on how much of the table is known all-visible. If the table is getting >> a lot of churn, or even just hasn't been vacuumed since it quiesced, >> the planner will prefer a seqscan for this --- and it will be right. >> > > Hmm. So it's something with my environment. > > Should the following setup qualify for an index scan? The seq scan is estimated to use sequential reads, while the index-only scan is estimated to use random reads (because the index is scanned in logical order, not physical order). If you set random_page_cost equal to seq_page_cost, that would artificially favor the index only scan. Also, your filler is highly compressible, which means the table is much smaller than you might think. Cheers, Jeff -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
