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