Re: get_actual_variable_range vs idx_scan/idx_tup_fetch - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Date
Msg-id 54429207.6060307@joh.to
Whole thread Raw
In response to Re: get_actual_variable_range vs idx_scan/idx_tup_fetch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
List pgsql-hackers
On 10/18/14, 5:46 PM, Tom Lane wrote:
> Marko Tiikkaja <marko@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.


.marko



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Next
From: Tom Lane
Date:
Subject: FieldSelect optimization versus overall planner organization