Re: Fix to not check included columns in ANALYZE on indexes
От | Peter Geoghegan |
---|---|
Тема | Re: Fix to not check included columns in ANALYZE on indexes |
Дата | |
Msg-id | CAH2-WzmBDvGU-RMvd8ZEn3K4TTg-bJ02Urvi3XkYN2BmwZN0xg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix to not check included columns in ANALYZE on indexes (Yugo Nagata <nagata@sraoss.co.jp>) |
Ответы |
Re: Fix to not check included columns in ANALYZE on indexes
|
Список | pgsql-hackers |
On Fri, Jun 29, 2018 at 1:31 AM, Yugo Nagata <nagata@sraoss.co.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
В списке pgsql-hackers по дате отправления: