Re: get_actual_variable_range vs idx_scan/idx_tup_fetch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(at)joh(dot)to>
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 15:46:47
Message-ID: 19929.1413647207@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Tiikkaja <marko(at)joh(dot)to> writes:
> On 10/18/14, 4:33 PM, Bruce Momjian wrote:
>> Well, if the index is there, why not use it? I thought the problem was
>> just that you had no visibility into how those statistics were being
>> accessed.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-10-18 16:15:03 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Previous Message Tom Lane 2014-10-18 15:05:48 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch