Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id DBDD86334E1 for ; Tue, 20 Apr 2010 16:22:47 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28470-08 for ; Tue, 20 Apr 2010 19:22:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gy0-f174.google.com (mail-gy0-f174.google.com [209.85.160.174]) by mail.postgresql.org (Postfix) with ESMTP id 6D1E0632F34 for ; Tue, 20 Apr 2010 16:22:37 -0300 (ADT) Received: by gyg13 with SMTP id 13so3354509gyg.19 for ; Tue, 20 Apr 2010 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TuXi5V28G8mgHdnVhamY+vv6jpcblF6BA6z9svxLQ+g=; b=o3SQt5N1XZW3g3NG6lnXJbYtQ0Fa3SFfXWNv83KjtOJsESiKQWg0Kxyq/fqOMcdUEL gLLzH90FIgrSHacXusVB2TPk4O73NcnvSHfQ3p6doijCjuHlmq4dzzC9bPenc0bpmsZ1 8mQyj5sHvAnZ9mznNIw1DKvdDKg75ygm5Fa2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kojk4VxvufTEMfXIgqbN2Fg2gLF0GmSKVyO6EKMdKIwo6qUCJ/XXHbfQtoKKEY6sxK yxlOw4oDtXZRmg1TgTDozCKH2OQxcHjR80DPyjqQq2ZiMU8PMtMQmGBm2hDNAJtp3miN IeaoEz6nmn1a9+KPpiQOJM4NkZBkaR8T51id0= MIME-Version: 1.0 Received: by 10.150.218.9 with HTTP; Tue, 20 Apr 2010 12:22:36 -0700 (PDT) In-Reply-To: <20100420184727.GE53489@mr-paradox.net> References: <20100420173936.GA50886@mr-paradox.net> <20100420180351.GA51940@mr-paradox.net> <20100420184727.GE53489@mr-paradox.net> Date: Tue, 20 Apr 2010 13:22:36 -0600 Received: by 10.151.4.8 with SMTP id g8mr7801503ybi.40.1271791356607; Tue, 20 Apr 2010 12:22:36 -0700 (PDT) Message-ID: Subject: Re: Very high effective_cache_size == worse performance? From: Scott Marlowe To: David Kerr Cc: Robert Haas , pgsql-performance@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001 X-Spam-Level: X-Archive-Number: 201004/259 X-Sequence-Number: 38509 On Tue, Apr 20, 2010 at 12:47 PM, David Kerr wrote: > On Tue, Apr 20, 2010 at 02:15:19PM -0400, Robert Haas wrote: > - On Tue, Apr 20, 2010 at 2:03 PM, David Kerr wrote: > - > that thought occured to me while I was testing this. I ran a vacuumdb= -z > - > on my database during the load and it didn't impact performance at al= l. > - > - The window to run ANALYZE usefully is pretty short. =A0If you run it > - before the load is complete, your stats will be wrong. =A0If you run it > - after the select statements that hit the table are planned, the > - updated stats won't arrive in time to do any good. > > right, but i'm loading 20 million records in 1000 record increments. so > the analyze should affect all subsequent increments, no? I keep thinking FK checks are taking a long time because they aren't cached because in import they went through the ring buffer in pg or some other way aren't in a buffer but large effective cache size says it's 99.99% chance or better that it's in cache, and chooses a poor plan to look them up. Just a guess.