Re: Index Scans become Seq Scans after VACUUM ANALYSE

Tom Lane wrote:

>mlw <markw(at)mohawksoft(dot)com> writes:
>
>>That is the difference, in another post Tom said he could not get
>>excited about 10.9 second execution time over a 7.96 execution
>>time. Damn!!! I would. That is wrong.
>>
>
>Sure. Show us how to make the planner's estimates 2x more accurate
>(on average) than they are now, and I'll get excited too.
>
>But forcing indexscan to be chosen over seqscan does not count as
>making it more accurate. (If you think it does, then you don't
>need to be in this thread at all; set enable_seqscan = 0 and
>stop bugging us ;-))
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
Do we have a tool that can analyze a table and indexes to allow the DBA
to choose when to add an index or when not too?

DB2 has an index analyizer like this. Given a specific query and the
current table stats it can tell you which indexes would be
most beneficial. Do we have something like this already?

At least we could point those DBA's to a utility like this and then they
would not be too suprised when the optimizer didn't use the index.

- Bill