Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XCPSt-0004m7-UI for pgsql-performance@arkaria.postgresql.org; Wed, 30 Jul 2014 08:42:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XCPSt-0008Ia-9S for pgsql-performance@arkaria.postgresql.org; Wed, 30 Jul 2014 08:42:27 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XCPSs-0008IU-DB for pgsql-performance@postgresql.org; Wed, 30 Jul 2014 08:42:26 +0000 Received: from smtp-out1.gransy.com ([77.78.126.51]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XCPSo-0007m8-W8 for pgsql-performance@postgresql.org; Wed, 30 Jul 2014 08:42:24 +0000 Received: from smtp-out.gransy.com (localhost [127.0.0.1]) by smtp-out1.gransy.com (Postfix) with ESMTP id CE61C36003A for ; Wed, 30 Jul 2014 10:42:18 +0200 (CEST) Received: from smtp.gransy.com (smtp.simplia.cz [77.78.126.20]) by smtp-out1.gransy.com (Postfix) with ESMTP id 8BCC0360038; Wed, 30 Jul 2014 10:42:18 +0200 (CEST) Received: from sq.gransy.com (elizabeth.gransy.com [89.187.132.199]) (Authenticated sender: tv@fuzzy.cz) by smtp.gransy.com (Postfix) with ESMTPA id BAF7C19A06EE; Wed, 30 Jul 2014 10:42:15 +0200 (CEST) Received: from 212.47.19.46 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Wed, 30 Jul 2014 10:42:17 +0200 Message-ID: <3e6b532b0115ffff08e8d0debd76695b.squirrel@sq.gransy.com> In-Reply-To: <53D84E16.90609@catalyst.net.nz> References: <53ACB190.2030206@catalyst.net.nz> <53ACD6C4.9050605@catalyst.net.nz> <20140627091951.GA16680@awork2.anarazel.de> <53B283F3.7020005@catalyst.net.nz> <20140701101307.GO21422@awork2.anarazel.de> <53BF326F.2070903@catalyst.net.nz> <20140711082207.GI17261@awork2.anarazel.de> <53C711B6.5040802@catalyst.net.nz> <53D84E16.90609@catalyst.net.nz> Date: Wed, 30 Jul 2014 10:42:17 +0200 Subject: Re: 60 core performance with 9.3 From: "Tomas Vondra" To: "Mark Kirkwood" Cc: "Andres Freund" , pgsql-performance@postgresql.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Pg-Spam-Score: -0.0 (/) 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 30 Červenec 2014, 3:44, Mark Kirkwood wrote: > > While these numbers look great in the middle range (12-96 clients), then > benefit looks to be tailing off as client numbers increase. Also running > with no stats (and hence no auto vacuum or analyze) is way too scary! I assume you've disabled statistics collector, which has nothing to do with vacuum or analyze. There are two kinds of statistics in PostgreSQL - data distribution statistics (which is collected by ANALYZE and stored in actual tables within the database) and runtime statistics (which is collected by the stats collector and stored in a file somewhere on the dist). By disabling statistics collector you loose runtime counters - number of sequential/index scans on a table, tuples read from a relation aetc. But it does not influence VACUUM or planning at all. Also, it's mostly async (send over UDP and you're done) and shouldn't make much difference unless you have large number of objects. There are ways to improve this (e.g. by placing the stat files into a tmpfs). Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance