Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhfQ9-0006j9-Rg for pgsql-performance@arkaria.postgresql.org; Tue, 15 Aug 2017 17:14:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dhfQ9-0000Yb-EI for pgsql-performance@arkaria.postgresql.org; Tue, 15 Aug 2017 17:14:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dhfQ8-0000YR-T8 for pgsql-performance@postgresql.org; Tue, 15 Aug 2017 17:14:24 +0000 Received: from mail-qt0-x22e.google.com ([2607:f8b0:400d:c0d::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dhfQ1-0002WR-4d for pgsql-performance@postgresql.org; Tue, 15 Aug 2017 17:14:24 +0000 Received: by mail-qt0-x22e.google.com with SMTP id v29so7749282qtv.3 for ; Tue, 15 Aug 2017 10:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9gootoQPsoVI3ufU3KuDuQCHZzzMRzepciQd8QUw1LI=; b=D6yY4nh32bV/flWUox4em3EGPS3PicHmFs5y/p8F+v63JB0eMHtF4Ct7T6bt0/GUQy tGcqq9vV/0kRLGVwRsqc+kkEfOlgc21dzk97FraiGj5awFgegEx2a4RBkPZOOuFOsnUt asrSRxPdZVoyj4Y8VjWhWv3gXgAcC8VV8sT5M8Ri1Td7iRRHZJf2REItz/Gji1urVaWm Zd4YtL8OpdwfReWm1D9WgYT5sfNie9z7VFdNwqxPlVz2Y1rw3yow+Diy04om05imdRBL hsBq/4DTxi7VVpP5ACCnPraagAF/YawfwI/ViQI8zDC4aXwudSp93/g6gCYKzFNyoEB2 eo4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9gootoQPsoVI3ufU3KuDuQCHZzzMRzepciQd8QUw1LI=; b=HUPRprgUo8WrZDSmP7JFXThPmosC4zYk0KTel8viwgw7btQrXmluYpOlqQZqa8clsS lwhXPCWQbhs2yiXzHsu0nD76B2qLaR0YGaPHTtkfpFPASTS7pLyz8WSJScYSD73BxWs+ v3X1A0ss6Ej5hbXSbm2kHCZTZOgJs+Amsx7wMdvQY3pMHrvL44Zk3Ec8aEG4PS7q4VGL rMuCGe++w/sz2QiMETqv3Hl9DiO009b9MZlF5k1k/jXizULXq5brsr2AngW8sav7C4LS zzlIXW2ASxR/1EmUEFXRYkU/cDh0j+P11lz96OzNspm6Y33UTOmLvlHbPddZvWTXWdYb JRiA== X-Gm-Message-State: AHYfb5immIffv0iJ8LzHBfXeQj3li3cQuH9tUbbdoxWWSgntJakgdKVu S970G3FjbHwIG82fmCtRQaOLj3V73g== X-Received: by 10.200.8.232 with SMTP id y37mr36847175qth.329.1502817255217; Tue, 15 Aug 2017 10:14:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.105.164 with HTTP; Tue, 15 Aug 2017 10:14:14 -0700 (PDT) In-Reply-To: References: From: Scott Marlowe Date: Tue, 15 Aug 2017 11:14:14 -0600 Message-ID: Subject: Re: performance problem on big tables To: Mariel Cherkassky Cc: "pgsql-performance@postgresql.org" Content-Type: text/plain; charset="UTF-8" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Tue, Aug 15, 2017 at 4:06 AM, Mariel Cherkassky 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 So 26G takes 95 minutes, or 27 MB/minute or 456k/second? Sound about right (it's early, I haven't had enough coffee please check my math). That's pretty slow unless you're working across pretty big distances with mediocre connections. My home internet downloads about 100MB/s by comparison. > \copy local_postresql_table from /tmp/tmp with binary - Didnt run because > the remote oracle database is currently under maintenance work. You shouldn't need the remote oracle server if you've already copied it over, you're just copying from local disk into the local pgsql db. Unless I'm missing something. > So I decided to follow MichaelDBA tips and I set the ram on my machine to > 16G and I configured the effective_cache memory to 14G,tshared_buffer to be > 2G and maintenance_work_mem to 4G. Good settings. Maybe set work_mem to 128MB or so while you're at it. > I started running the copy checks again and for now it coppied 5G in 10 > minutes. I have some questions : > 1)When I run insert into local_postresql_table select * from > remote_oracle_table I insert that data as bulk to the local table or row by > row ? If the answer as bulk than why copy is a better option for this case > ? insert into select from oracle remote is one big copy, but it will take at least as long as copying from oracle to the local network took. Compare that to the same thing but use file_fdw on the file locally. > 2)The copy from dump into the postgresql database should take less time than > the copy to dump ? Yes. The copy from Oracle to your local drive is painfully slow for a modern network connection. > 3)What do you think about the new memory parameters that I cofigured ? They should be OK. I'm more worried about the performance of the io subsystem tbh. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance