Re: Index Scans become Seq Scans after VACUUM ANALYSE - Mailing list pgsql-hackers

From Bill Cunningham
Subject Re: Index Scans become Seq Scans after VACUUM ANALYSE
Date
Msg-id 3CBDF518.3070102@ballydev.com
Whole thread Raw
In response to Re: Index Scans become Seq Scans after VACUUM ANALYSE  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:

>mlw <markw@mohawksoft.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@postgresql.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




pgsql-hackers by date:

Previous
From: Manuel Sugawara
Date:
Subject: Re: regexp character class locale awareness patch
Next
From: Bruce Momjian
Date:
Subject: Re: regexp character class locale awareness patch