Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XTKYQ-00082O-8B for pgsql-admin@arkaria.postgresql.org; Mon, 15 Sep 2014 00:54:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XTKYP-00033Q-4u for pgsql-admin@arkaria.postgresql.org; Mon, 15 Sep 2014 00:54:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XTKYN-00033H-T9 for pgsql-admin@postgresql.org; Mon, 15 Sep 2014 00:54:04 +0000 Received: from mail-pd0-x236.google.com ([2607:f8b0:400e:c02::236]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XTKYJ-0004ng-7j for pgsql-admin@postgresql.org; Mon, 15 Sep 2014 00:54:02 +0000 Received: by mail-pd0-f182.google.com with SMTP id w10so5153260pde.41 for ; Sun, 14 Sep 2014 17:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=7QyhPBgKYTUd3vtJIgjSlfYplFuhpcXa1+uGETKETxQ=; b=qbmSmHpul39xslRGEeM2bV6UiXRf5anHqWCX+4Z92g4mr8dVt0ywr2CZ29yMUWW1R1 5bifGOjSC+ThfhXtyK3EewI8mMltbADWxqK3iE9+On9es4u6vicDoFeQgyAnHzbNxpPO lPU8tRKPin/xoKunkTsk+mmnp3j1IirI1qpNDm9P569kfPq54eZMDX5ZWN5wy0rZyDUf xUE/VApMFo3490qk2Lr9koHBu3UxzT6r4/z1F61T/0Otsfmdo1UzZrIIrA1TVYQCLO1t U59CXySsPQQw6n15iaNY8QxH779QI0fbv3qzji8pXrqlSxQvwgtT7/QDn47bHbuacrks 5Wlw== X-Received: by 10.70.89.165 with SMTP id bp5mr38115pdb.142.1410742435254; Sun, 14 Sep 2014 17:53:55 -0700 (PDT) Received: from Heretic (ip72-197-173-101.sd.sd.cox.net. [72.197.173.101]) by mx.google.com with ESMTPSA id xu4sm10110176pab.30.2014.09.14.17.53.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Sep 2014 17:53:53 -0700 (PDT) From: "Morgan Ramsay" To: "'Rosser Schwarz'" Cc: "'PgSQL ADMIN'" References: <1a9b601cfd07a$a16c71a0$e44554e0$@gmail.com> In-Reply-To: Subject: Re: Out of memory running 560 MB query Date: Sun, 14 Sep 2014 17:53:39 -0700 Message-ID: <000001cfd07f$7e577ac0$7b067040$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CFD044.D1F93F00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHyoDfDIMwHaIn9ozECB0XQXJ9dXgEW1zpTm7MFw6A= Content-Language: en-us X-Antivirus: avast! (VPS 140914-1, 09/14/2014), Outbound message X-Antivirus-Status: Clean X-Pg-Spam-Score: -1.7 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multipart message in MIME format. ------=_NextPart_000_0001_01CFD044.D1F93F00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry, I was running the query on what appeared to be a cached copy of = the old table=E2=80=94or something. =20 After a reboot, everything seems to be working. The admin client = wasn=E2=80=99t responding but now all of my data is there. =20 With regard to the list, I wasn=E2=80=99t sure whether there was a .conf = setting that limited the size of queries or whether there was a query = size limit. =20 =E2=80=94Morgan =20 =20 From: Rosser Schwarz [mailto:rosser.schwarz@gmail.com]=20 Sent: Sunday, September 14, 2014 5:28 PM To: Morgan Ramsay Cc: PgSQL ADMIN Subject: Re: [ADMIN] Out of memory running 560 MB query =20 On Sun, Sep 14, 2014 at 5:18 PM, Morgan Ramsay = wrote: Any idea how to successfully run a query that large? What=E2=80=99s the = size limit of a query? =20 Without seeing your actual query (or a syntactically similar one, if = there are private details you can't disclose), it's difficult to say. = In general, though, a couple of thoughts come to mind: =20 Can you run it as a single COPY statement, instead of however many = individual INSERTS? Failing that, can you use the multi-row VALUES = syntax for your INSERT? =20 As an aside, this type of question is probably more suited for the = pgsql-sql list, rather than -admin. =20 rls =20 --=20 :wq=20 ------=_NextPart_000_0001_01CFD044.D1F93F00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sorry, I = was running the query on what appeared to be a cached copy of the old = table=E2=80=94or something.

 =

After a = reboot, everything seems to be working. The admin client wasn=E2=80=99t = responding but now all of my data is there.

 =

With = regard to the list, I wasn=E2=80=99t sure whether there was a .conf = setting that limited the size of queries or whether there was a query = size limit.

 =

=E2=80=94Mo= rgan

 =

 =

From:= = Rosser Schwarz [mailto:rosser.schwarz@gmail.com]
Sent: = Sunday, September 14, 2014 5:28 PM
To: Morgan = Ramsay
Cc: PgSQL ADMIN
Subject: Re: [ADMIN] Out of = memory running 560 MB query

 

On = Sun, Sep 14, 2014 at 5:18 PM, Morgan Ramsay <morgan.ramsay@gmail.com> = wrote:

Any idea = how to successfully run a query that large? What=E2=80=99s the size = limit of a query?

 

Without seeing your actual query (or a syntactically = similar one, if there are private details you can't disclose), it's = difficult to say.  In general, though, a couple of thoughts come to = mind:

 

Can = you run it as a single COPY statement, instead of however many = individual INSERTS?  Failing that, can you use the multi-row VALUES = syntax for your INSERT?

 

As an aside, this type of question is probably more = suited for the pgsql-sql list, rather than = -admin.

 

rls

 

-- =
:wq

------=_NextPart_000_0001_01CFD044.D1F93F00--