Two small issues related to table_relation_copy_for_cluster() and CTAS with no data.

From: Paul Guo <paulguo(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Two small issues related to table_relation_copy_for_cluster() and CTAS with no data.
Date: 2022-04-21 06:29:59
Message-ID: CABQrizes0afi0z-vUUSxDec690q3wy2Wu7faxqS2NUKZ9dOe0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello hackers,

While reading the latest master branch code, I found something that we
may be able to improve.

1. The am table_relation_copy_for_cluster() interface.

static inline void
table_relation_copy_for_cluster(Relation OldTable, Relation NewTable,
Relation OldIndex,
bool use_sort,
TransactionId OldestXmin,
TransactionId *xid_cutoff,
MultiXactId *multi_cutoff,
double *num_tuples,
double *tups_vacuumed,
double *tups_recently_dead)

- Should add a line for parameter num_tuples below "Output parameters
" in comment
- Look at the caller code, i.e. copy_table_data(). It does initialize
*num_tuples,
*tups_vacuumed and *tups_recently_dead at first. This does not seem
to be a good
API design or implementation. We'd better let the am api return the
values without
initializing from callers, right?

2. For CTAS (create table as) with no data. It seems that we won't run
into intorel_receive().
intorel_startup() could be run into for "create table as t1
execute with no data". So it looks
like we do not need to judge for into->skipData in
intorel_receive(). If we really want to
check into->skipData we could add an assert check there or if I
missed some code paths
in which we could be run into the code branch, we could instead
call below code in
intorel_receive() to stop early, right?

if (myState->into->skipData)
return false;

Regards,
Paul

Browse pgsql-hackers by date

  From Date Subject
Next Message bucoo@sohu.com 2022-04-21 06:38:22 Re: Re: fix cost subqueryscan wrong parallel cost
Previous Message Masahiko Sawada 2022-04-21 04:59:50 Re: Logical replication timeout problem