Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fyQnD-0002Gd-O3 for pgsql-performance@arkaria.postgresql.org; Sat, 08 Sep 2018 00:08:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fyQnB-0000Wj-HQ for pgsql-performance@arkaria.postgresql.org; Sat, 08 Sep 2018 00:08:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fyQnB-0000Vx-3x for pgsql-performance@lists.postgresql.org; Sat, 08 Sep 2018 00:08:01 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fyQkb-0000Ob-BM for pgsql-performance@postgresql.org; Sat, 08 Sep 2018 00:05:22 +0000 Received: by mail-pg1-x542.google.com with SMTP id b129-v6so7693878pga.13 for ; Fri, 07 Sep 2018 17:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=Y1XPjaR3977hkM/P5NWs1E5Nrkinf0NJ41hVj5SmyHo=; b=eL5ipBD+ofizPBZvU4BZ4EI0nARw49dy6ZXdXRmWK1slexAxw7XuE7IFekXAfpb0OM ui7raGMj6qQtV6V9dUj80Za4hOvQTssIt9QHgOVyXfywPYa6VHNmxHGsghOX+tnzL3Lq 2dKMmb1rwJw3Brz53GBVqkhj7EpkYSRe+TLnf3JYYJ3leUP0sO+d0MBu0r0cJtXVryn7 T4xtrCI9dR9x2wLUPX85so6bQ/jxohCD2CgKa3U4+JelVe2J0WDb9CejYiBwyo5lnytc NviKIFrvX0z5IQGOcOi4XQ5QFrf8giFsAsvYDrjmYRhXTn/8GvL0egmjLtPeda+ytJAO it7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=Y1XPjaR3977hkM/P5NWs1E5Nrkinf0NJ41hVj5SmyHo=; b=rD5QdTby8Co+a4pB2KXzBzAPdpz+ubRkT1DxrIUlaHzAl/iL8JdUksG1PMKCYD9RqU nWnhQ31G5wWm8HWzIZIwAC94v/fezVjaDs5ezcI6N6iEN+go1KVKVD7H/9BvdqREYdIo baoqPbTdnIfKvUxXw+wU8/pliGnAd/r+G+QFOXIURUsf1pqnwD5csWr1L7EXSn0hnnIB srPTKwv61oTKiQywgeaEUmjDHo8f2h4euIWziHnL9KEX2V890TV9TTZ3gBz2b8l3CS5y yIQX9lpUrM9PoKXScigVlLOWz5OaXS1su2gtfdcqhoiukJ+61Do4Mhp3/FH5xm4vLV7Q rhxw== X-Gm-Message-State: APzg51CjeD9HWunuuVLtkgCeGX7SYfiD1KPzSzL9XbFiN1jrIEmbYYWq Q+61KtW7nYrDNFYJvqZz8IsttkrD X-Google-Smtp-Source: ANB0VdYYo5+IgSaQwjigtr2qo7kso43+rwA3smqY59xzdXvPdN1NT+B+22zvwg1MJ96pRIDqsbIBlg== X-Received: by 2002:a63:610:: with SMTP id 16-v6mr10586867pgg.96.1536365119270; Fri, 07 Sep 2018 17:05:19 -0700 (PDT) Received: from tim-desktop (2001-44b8-31f2-bb00-0428-b0ec-a40c-875f.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:428:b0ec:a40c:875f]) by smtp.gmail.com with ESMTPSA id o20-v6sm19674748pfj.35.2018.09.07.17.05.16 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 07 Sep 2018 17:05:18 -0700 (PDT) References: <1536339842382-0.post@n3.nabble.com> User-agent: mu4e 0.9.18; emacs 26.1 From: Tim Cross To: padusuma Cc: pgsql-performance@postgresql.org Subject: Re: Performance of INSERT into temporary tables using psqlODBC driver In-reply-to: <1536339842382-0.post@n3.nabble.com> Date: Sat, 08 Sep 2018 10:05:10 +1000 Message-ID: <8736uk6eh5.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk padusuma writes: > I am working on adding support for PostgreSQL database for our application. > In a lot of our use-cases, data is inserted into temporary tables using > INSERT INTO statements with bind parameters, and subsequently queries are > run by joining to these temp tables. Following is some of the data for these > INSERT statements: > > Table definition: CREATE TEMPORARY TABLE Table1( auid varchar(15) ) ON > COMMIT DELETE ROWS; > > SQL statement: INSERT INTO Table1 (uidcol) VALUES (:1); > > Time taken to insert 24428 rows: 10.077 sec > Time taken to insert 32512 rows: 16.026 sec > Time taken to insert 32512 rows: 15.821 sec > Time taken to insert 6107 rows: 1.514 sec > > I am looking for suggestions to improve the performance of these INSERT > statements into temporary tables. Database is located on a Linux VM and the > version is "PostgreSQL 10.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) > 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit". The application is running on a > windows platform and connecting to the database using psqlODBC driver > version 10.03. > We are inserting large numbers (millions) of rows into a postgres database from a Javascript application and found using the COPY command was much, much faster than doing regular inserts (even with multi-insert commit). If you can do this using the driver you are using, that will give you the largest performance boost. -- Tim Cross