| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Subject: | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt |
| Date: | 2025-11-14 04:06:49 |
| Message-ID: | CACJufxG2EpBv_ZskXyD+hLgWeLxzPPgEBM65HJOn7qtPNhUWAQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 13, 2025 at 5:41 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> On 2025-Nov-13, jian he wrote:
>
> > @@ -15658,10 +15658,19 @@ ATPostAlterTypeParse(Oid oldId, Oid oldRelId, Oid refRelId, char *cmd,
> > querytree_list = list_concat(querytree_list, afterStmts);
> > }
> > else if (IsA(stmt, CreateStatsStmt))
> > + {
> > + RangeTblEntry *rte;
> > + CreateStatsStmt *ss = castNode(CreateStatsStmt, stmt);
> > +
> > + rte = makeNode(RangeTblEntry);
> > + rte->rtekind = RTE_RELATION;
> > + rte->relid = oldRelId;
> > + rte->rellockmode = ShareUpdateExclusiveLock;
> > + ss->rtable = list_make1(rte);
> > +
> > querytree_list = lappend(querytree_list,
> > - transformStatsStmt(oldRelId,
> > - (CreateStatsStmt *) stmt,
> > - cmd));
> > + transformStatsStmt(ss, cmd));
> > + }
> > else
> > querytree_list = lappend(querytree_list, stmt);
> > }
>
> Hmm, how would this part here work in the hypothetical world where a
> stats object references multiple relations?
>
hi.
per
https://www.postgresql.org/docs/current/catalog-pg-statistic-ext.html
extended statistics either based on column name or expression.
If based on column name, imagine a simple case:
CREATE STATISTICS ON a FROM t1,t2;
pg_statistic_ext obviously needs another column to store other relation oids.
in this case, we can use AlteredTableInfo->changedStatisticsOids to lookup
catalog table pg_statistic_ext to find out the associated relation oids
If extended statistics is based on expression, imagine a simple case:
CREATE STATISTICS on (t1.a + t2.a) from t1, t2;
ruleutils.c can not cope with expressions like: "(t1.a + t2.a)",
so we have to wrap the expression into a Query Node, store it in
pg_statistic_ext.stxexprs.
If pg_statistic_ext does not contain all associated relation
OIDs, all these pg_get_statisticsobjdef_expressions won't work
pg_statistic_ext should contain all associated relation OIDs, in my opinion. If
pg_statistic_ext does store all related relation OIDs, then the potential issue
you mentioned above should be solvable.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2025-11-14 04:10:00 | Re: SQL:2011 Application Time Update & Delete |
| Previous Message | 高增琦 | 2025-11-14 04:02:30 | Compile error on the aarch64 platform: Missing asm/hwcap.h |