| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: performance problem on big tables |
| Date: | 2017-08-15 16:13:30 |
| Message-ID: | CAMkU=1zh2iGYVriwcMOXS8GB7BKB-k6Am1xK6H1LUh_-RwLjqQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Aug 15, 2017 at 3:06 AM, Mariel Cherkassky <
mariel(dot)cherkassky(at)gmail(dot)com> wrote:
> Hi,
> So I I run the cheks that jeff mentioned :
> \copy (select * from oracle_remote_table) to /tmp/tmp with binary - 1 hour
> and 35 minutes
> \copy local_postresql_table from /tmp/tmp with binary - Didnt run because
> the remote oracle database is currently under maintenance work.
>
The "\copy...from" doesn't depend on oracle, it would be only depend on
local file system (/tmp/tmp), provided that the "\copy...to" finished.
Anyway, given the length of time it took, I think you can conclude the
bottleneck is in oracle_fdw itself, or in Oracle, or the network.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2017-08-15 17:04:58 | Re: Odd sudden performance degradation related to temp object churn |
| Previous Message | Jeremy Finzel | 2017-08-15 16:00:44 | Re: Odd sudden performance degradation related to temp object churn |