Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics
Date
Msg-id 2135832.1715885118@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics  (Tender Wang <tndrwang@gmail.com>)
Responses Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics
Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics
List pgsql-bugs
Tender Wang <tndrwang@gmail.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.

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().

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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18469: OOM occurs and backend processes are kept in Zombie state.
Next
From: Andres Freund
Date:
Subject: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae