Re: get_actual_variable_range vs idx_scan/idx_tup_fetch

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Date: 2014-10-18 16:15:03
Message-ID: 54429207.6060307@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/18/14, 5:46 PM, Tom Lane wrote:
> Marko Tiikkaja <marko(at)joh(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-18 16:48:16 FieldSelect optimization versus overall planner organization
Previous Message Tom Lane 2014-10-18 15:46:47 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch