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

Поиск
Список
Период
Сортировка
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18469: OOM occurs and backend processes are kept in Zombie state.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae