Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Subject: Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics
Date: 2024-05-17 03:26:26
Message-ID: CAHewXN=g6ZtgpqygFVNJh2sjR93Jcxb0owuY1ANJfE6wuf0FkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2024年5月17日周五 02:45写道:

> Tender Wang <tndrwang(at)gmail(dot)com> writes:
> > generateClonedExtStatsStmt just copy t0's ext_stat info to t1.
>
> So this is a complete mess. The fundamental problem is that
> transformTableLikeClause believes it can process LIKE_STATISTICS
> requests immediately, because:
>
> * We may copy extended statistics if requested, since the
> representation
> * of CreateStatsStmt doesn't depend on column numbers.
>

The above comments in transformTableLikeClause and below comments in
generateClonedExtStatsStmt:
* Now handle expressions, if there are any. The order (with respect to
* regular attributes) does not really matter for extended stats, so we
* simply append them after simple column references.
now should do some revise.

That was true apparently in the original, limited implementation
> where we only supported CREATE STATISTICS on plain columns.
> It's completely wrong for statistics on expressions. IMO what we
> need to do is make LIKE_STATISTICS work more like LIKE_INDEXES:
> postpone the transformation until expandTableLikeClause when we know
> the mapping from source columns to destination columns, and have a
> chance at converting the expression trees properly, comparably to
> generateClonedIndexStmt.

> Right now, there is nothing to do in transformExtendedStatistics.
> > Can we update the varattno to the right value here?
>
> We don't know the column mapping there, either. What we need to have
> our hands on is the "attmap" computed in expandTableLikeClause, and
> then we can pass the stats expressions through map_variable_attnos().

This fix looks better than what I said in transformExtendedStatistics.

>
I think this might not need to be a really large patch, but it
> definitely has to change where generateClonedExtStatsStmt is
> called from. I can have a go at it if Tomas doesn't want to.
>
> regards, tom lane
>

--
Tender Wang
OpenPie: https://en.openpie.com/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bowen Shi 2024-05-17 03:35:53 Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Previous Message Japin Li 2024-05-17 02:45:39 Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption