On Sat, Oct 18, 2014 at 06:15:03PM +0200, Marko Tiikkaja wrote: > On 10/18/14, 5:46 PM, Tom Lane wrote: > >Marko Tiikkaja <ma...@joh.to> writes: > >>Yes, exactly; if I had had the option to disable the index from the > >>optimizer's point of view, I'd have seen that it's not used for looking > >>up any data by any queries, and thus I would have known that I can > >>safely drop it without slowing down queries. Which was the only thing I > >>cared about, and where the stats we provide failed me. > > > >This argument is *utterly* wrongheaded, because it assumes that the > >planner's use of the index provided no benefit to your queries. If the > >planner was touching the index at all then it was planning queries in > >which knowledge of the extremal value was relevant to accurate selectivity > >estimation. So it's quite likely that without the index you'd have gotten > >different and inferior plans, whether or not those plans actually chose to > >use the index. > > Maybe. But at the same time that's a big problem: there's no way of > knowing whether the index is actually useful or not when it's used > only by the query planner.
That is a good point. Without an index, the executor is going to do a sequential scan, while a missing index to the optimizer just means worse statistics. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
