| From: | Shane Borden <sborden76(at)gmail(dot)com> |
|---|---|
| To: | Rob Sargent <robjsargent(at)gmail(dot)com> |
| Cc: | pgsql-sql(at)lists(dot)postgresql(dot)org |
| Subject: | Re: PARALLEL CTAS |
| Date: | 2022-12-12 17:36:11 |
| Message-ID: | 7BD04D8E-9307-4107-B4D0-4C281390F996@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
I saw this as an option. Let’s say you have a million row table. If you copy from STDIN, do you have to spool the source table to a local file first? Looking to replace a CTAS thats doing this all within SQL statements now.
---
Thanks,
Shane Borden
sborden76(at)gmail(dot)com
> On Dec 12, 2022, at 12:25 PM, Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
> On 12/12/22 10:13, Shane Borden wrote:
>> The issue is there are certain performance benefits to be had by doing parallel CTAS operations and when converting from Oracle to PostgreSQL switching to a “COPY” operation isn’t feasible.
>> ---
>>
>> Thanks,
>>
> 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)
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Midgley | 2022-12-12 18:19:00 | Re: PARALLEL CTAS |
| Previous Message | Rob Sargent | 2022-12-12 17:25:08 | Re: PARALLEL CTAS |