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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tender Wang <tndrwang(at)gmail(dot)com>
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-16 18:45:18
Message-ID: 2135832.1715885118@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2024-05-16 19:39:53 Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Previous Message Tom Lane 2024-05-16 17:23:37 Re: BUG #18469: OOM occurs and backend processes are kept in Zombie state.