Use plain "create table as" if possible

[Melkij]

Hello

We need to split the copying of data into the new table into separate commands if we need any per-column storage settings.
In this case we must use this order:

• create table as .. with no data;
• alter table .. alter column ..
• insert into .. select

But this is pointless if we don't need to change the column.
At the same time, a single "create table as" command may be very useful for performing --order-by because it may use parallel query execution feature in PostgreSQL. INSERT .. SELECT currently cannot use parallel plans.

[dvarrazzo]

This is interesting, but I wonder what is the locking behaviour?

If a CREATE TABLE AS takes a long time, is the system catalog locked? Can you run concurrent DDL instructions concurrently?

[Melkij]

is the system catalog locked?

There is no such global system catalog locking in postgresql.

Can you run concurrent DDL instructions concurrently?

On other objects - yes. You will wait transaction with another create table with same tablename in same schema, but running of two parallel pg_repack is already wrong idea. pg_repack also forbid DDL on processed table (by holding explicit lock table).

Also transaction locks released only at commit (or rollback). LWLock should not holding in long time (otherwise it's postgresql bug). So here is no actual difference in behaviour, currently create table and insert select are called in same transaction.

[xzilla]

In non-parallel cases, this seems like it might cause repack to be slower, but the locking mechanics are no worse, so it should be just as safe as the current repack.

[Melkij]

In non-parallel cases, this seems like it might cause repack to be slower

hm, why?

[xzilla]

You'll have to sort the data before it can be inserted; the larger the table, the more expensive / time consuming that process will be. I don't see it as a show stopper, but something people may want to think about (especially as I don't see a lot of systems being well tuned for parallel work).

[Melkij]

Right. But there is no performance regression:

• when cluster mode was requested (by --order-by= option or table was clustered) currently we going to insert .. select .... order by ... - which is always non-parallel. create table as in worst case will be the same.
• but when cluster mode was not requested (table was not clustered or --no-order option), we have no order by clause at all.

[andreasscherbaum]

@Melkij Any way you can test the correct creation of the table, with all options and also include the order by?

[bz007]

@Melkij would you update the patch?