Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 57C439FA0EE for ; Fri, 1 Dec 2006 04:55:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 47605-02 for ; Fri, 1 Dec 2006 04:55:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.barettadeit.com (unknown [213.255.109.130]) by postgresql.org (Postfix) with ESMTP id 694109F9EED for ; Fri, 1 Dec 2006 04:55:40 -0400 (AST) Received: from [10.0.0.10] (alex.barettalocal.com [10.0.0.10]) by mail.barettadeit.com (Postfix) with ESMTP id CB14F5044; Fri, 1 Dec 2006 09:55:37 +0100 (CET) Message-ID: <456FEE09.40905@studio.baretta.com> Date: Fri, 01 Dec 2006 09:55:37 +0100 From: Alessandro Baretta User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Tom Lane Cc: pgsql-performance@postgresql.org Subject: Re: NAMEDATALEN and performance References: <456D6FAB.4030400@studio.baretta.com> <19764.1164815445@sss.pgh.pa.us> In-Reply-To: <19764.1164815445@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.068 tagged_above=0 required=5 tests=AWL, BAYES_50, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200612/2 X-Sequence-Number: 22058 Tom Lane wrote: > Alessandro Baretta writes: >> I am considering the possibility of rebuilding the server with >> NAMEDATALEN equal to 256. I have seen an interesting thread [1] about >> the performance impact of raising NAMEDATALEN, but it did not seem >> conclusive. > > More to the point, tests done on 7.2-era code shouldn't be assumed to be > relevant to modern PG releases. I think you'll need to do your own > benchmarking if you want to find out the costs of doing this. > > regards, tom lane > That's sensible. Now, performance in my case is much less critical than the robustness and scalability of the application, so I guess I could just leave it to that and go with raising namedatalen. Yet, I would like to receive some insight on the implications of such a choice. Beside the fact that the parser has more work to do to decipher queries and whatnot, what other parts of the server would be stressed by a verbose naming scheme? Where should I expect the bottlenecks to be? Also, I could imagine a solution where I split the names in a schema part and a local name, thereby refactoring my namespace. I'd get the approximate effect of doubling namedatalen, but at the expense of having a much wider searchpath. Based on your experience, which of two possible strategies is more prone to cause trouble? Alex -- ********************************************************************* Ing. Alessandro Baretta Studio Baretta http://studio.baretta.com/ Consulenza Tecnologica e Ingegneria Industriale Technological Consulting and Industrial Engineering Headquarters tel. +39 02 370 111 55 fax. +39 02 370 111 54 Lab tel. +39 02 9880 271 fax. +39 02 9828 0296