Re: PARALLEL CTAS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Midgley <science(at)misuse(dot)org>
Cc: Shane Borden <sborden76(at)gmail(dot)com>, Rob Sargent <robjsargent(at)gmail(dot)com>, pgsql-sql(at)lists(dot)postgresql(dot)org
Subject: Re: PARALLEL CTAS
Date: 2022-12-12 18:52:13
Message-ID: 2033540.1670871133@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-sql

>> Today I suspect you're left with something like the following:
>> - CTAS from source where 1=2 (i.e. table definition via select semantics)
>> - copy from stdin (filled with intended CTAS select)

As far as I can tell, all supported versions of Postgres are perfectly
content to parallelize the source-row computation in a CREATE TABLE AS
SELECT, if they would parallelize the underlying SELECT. Note that
this is not the same as INSERT INTO ... SELECT, which is a harder
problem because the target table might already have indexes, constraints,
etc.

If what you are concerned about is parallelization of the physical
insertions of the tuples, I'm pretty sure we don't have anything that
can do that today, including COPY. COPY does have some batch-insertion
optimizations, but that's not parallelism.

Can you parallelize your problem at a higher level, ie do several
table loads at once?

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Shaozhong SHI 2022-12-12 22:43:08 Tom changed his job role many times
Previous Message Steve Midgley 2022-12-12 18:19:00 Re: PARALLEL CTAS