Re: get_actual_variable_range vs idx_scan/idx_tup_fetch

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(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 14:46:42
Message-ID: 20141018144642.GE16974@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 18, 2014 at 04:38:37PM +0200, Marko Tiikkaja wrote:
> On 10/18/14, 4:33 PM, Bruce Momjian wrote:
> >On Sat, Oct 18, 2014 at 04:29:41PM +0200, Marko Tiikkaja wrote:
> >>Another idea had was some way to tell the optimizer not to use that
> >>particular index for stats lookups, but probably the use case for
> >>such a feature would be a bit narrow.
> >
> >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.

How many other cases do we have where the statistics are getting
incremented and there is no user visibility into the operation?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-18 15:05:48 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch
Previous Message Thomas Kellerer 2014-10-18 14:40:55 Re: Materialized views don't show up in information_schema