Re: Fix to not check included columns in ANALYZE on indexes

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix to not check included columns in ANALYZE on indexes
Date: 2018-06-30 17:56:37
Message-ID: CAH2-WzmBDvGU-RMvd8ZEn3K4TTg-bJ02Urvi3XkYN2BmwZN0xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 29, 2018 at 1:31 AM, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
> I'm sorry but I don't understand why we'd just have to revert this patch later.
>
> Do you mean that if we decide to support expressions in included columns in future,
> this patch would be reverted? This is wrong. To my understanding, statistics on
> included (= non-key) columns in index is never used by the planner whether this
> is expression or not. So, we don't have to examin these columns in ANALYZE.

I think that the argument Tom is making is that it might be useful to
have statistics on the expression regardless of this -- the expression
may be interesting in some general sense. For example, one can imagine
the planner creating a plan with a hash aggregate rather than a group
aggregate, but only when statistics on an expression are available,
somehow. Those statistics may only be available because of the
appearance of the expression as a non-key attribute (in a future world
where expressions as non-key attributes are accepted, and index-only
scans work with expressions).

In the past, we talked about adding a feature that made this happen
for expressions without requiring any index at all, which Tom referred
to in passing. That's why I understand his remarks in this way.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brad DeJong 2018-06-30 18:11:05 Re: Postgres 11 release notes
Previous Message Brad DeJong 2018-06-30 16:42:44 Re: PostgreSQL vs SQL Standard