Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1afwzj-00024G-Kl for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Mar 2016 21:59:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1afwzj-0000Xl-3H for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Mar 2016 21:59:15 +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 1afwzh-0000Wv-Lm for pgsql-hackers@postgresql.org; Tue, 15 Mar 2016 21:59:13 +0000 Received: from out.smtp-auth.no-ip.com ([8.23.224.60]) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1afwzY-00011q-38 for pgsql-hackers@postgresql.org; Tue, 15 Mar 2016 21:59:12 +0000 X-No-IP: alvh.no-ip.org@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from alvin.alvh.no-ip.org (unknown [186.37.18.27]) (Authenticated sender: alvh.no-ip.org@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id C0DAC4012D5; Tue, 15 Mar 2016 14:58:54 -0700 (PDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 3EB865CC; Tue, 15 Mar 2016 18:58:50 -0300 (CLT) Date: Tue, 15 Mar 2016 18:58:50 -0300 From: Alvaro Herrera To: Fabien COELHO Cc: Michael Paquier , "pgsql-hackers@postgresql.org" Subject: Re: pgbench stats per script & other stuff Message-ID: <20160315215850.GA41105@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -1.1 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Fabien COELHO wrote: > >If somebody specifies thousands of -f switches, they will waste a few > >bytes with each, but I'm hardly concerned about a few dozen kilobytes > >there ... > > Ok, so you prefer a memory leak. I hate it on principle. I don't "prefer" memory leaks -- I prefer interfaces that make sense. Speaking of which, I don't think the arrangement in your patch really does. I know I suggested it, but now that I look again, it turns out I chose badly and you implemented a bad idea, so can we go back and fix it, please? What I now think should really happen is that the current sql_scripts array, currently under an anonymous struct, should be a typedef, say ParsedScript, and get a new member for the weight; process_file and process_builtin return a ParsedScript. The weight and Command ** should not be part of script_t at all. In fact, with ParsedScript I don't think we need to give a name to the anon struct used for builtin scripts. Rename the current sql_scripts.name to "desc", to mirror what is actually put in there from the builtin array struct. Make addScript receive a ParsedScript and weight, fill in the weight into the struct, and put it to the array after sanity-checking. (I'm OK with keeping "name" instead of renaming to "desc", if that change becomes too invasive.) No need for N_BUILTIN; we can use lengthof(builtin_script) instead. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers