From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: Allowing extended stats on foreign and partitioned tables |
Date: | 2017-04-10 10:18:42 |
Message-ID: | CAFjFpRcJntzyR8E6GXqRk3Fa_s_Pw=gmANc_bYVjAF=QCkD_ww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
This isn't exactly about this particular thread. But I noticed, that
after we introduced RELKIND_PARTITIONED_TABLE, we required to change a
number of conditions to include this relkind. We missed some places in
initial commits and fixed those later. I am wondering whether we
should creates macros clubbing relevant relkinds together based on the
purpose of the tests e.g. IS_RELKIND_HAS_STORAGE(). When a new relkind
is added, one can examine these macros to check whether the new
relkind fits in the given macro. If all those macros are placed
together, there is a high chance that we will not miss any place in
the initial commit itself.
For example, if we had a macro IS_RELKIND_WITH_STATS defined as
#define IS_RELKIND_WITH_STATS(relkind) \
((relkind) == RELKIND_RELATION || \
(relkind) == RELKIND_MATVIEW)
and CreateStatistics() and getExtendedStatistics() had following conditions
if (!IS_RELKIND_WITH_STATS(rel->rd_rel->relkind)) and if
(!IS_RELKIND_WITH_STATS(tabinfo->relkind)) resp. The patch would be
just adding
(relkind) == RELKIND_FOREIGN_TABLE || \
(relkind) == RELKIND_PARTITIONED_TABLE)
to that macro without requiring to find out where all we need to add
those two relkinds for statistics purposes.
On Mon, Apr 10, 2017 at 3:09 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> While reviewing extended stats I noticed that it was possible to
> create extended stats on many object types, including sequences. I
> mentioned that this should be disallowed. Statistics were then changed
> to be only allowed on plain tables and materialized views.
>
> This should be relaxed again to allow anything ANALYZE is allowed on.
>
> The attached does this.
>
> --
> David Rowley http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2017-04-10 10:46:51 | Re: Proposal: Local indexes for partitioned table |
Previous Message | David Rowley | 2017-04-10 10:12:53 | pg_stats_ext view does not seem all that useful |