X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 557D5D1B551 for ; Tue, 14 Oct 2003 17:14:24 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 50414-02 for ; Tue, 14 Oct 2003 14:13:54 -0300 (ADT) Received: from davinci.ethosmedia.com (unknown [209.128.84.228]) by svr1.postgresql.org (Postfix) with ESMTP id 0E210D1B58D for ; Tue, 14 Oct 2003 14:12:11 -0300 (ADT) Received: from [63.195.55.98] (HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.0.2) with ESMTP id 3767271; Tue, 14 Oct 2003 10:12:43 -0700 Content-Type: text/plain; charset="iso-8859-2" From: Josh Berkus Organization: Aglio Database Solutions To: "Ivan Voras" , Subject: Re: go for a script! / ex: PostgreSQL vs. MySQL Date: Tue, 14 Oct 2003 10:09:26 -0700 User-Agent: KMail/1.4.3 References: <20031012213527.BB2B61CB4664@svr4.postgresql.org> <00af01c39112$d9ac4350$bf8ec6c1@flatline> In-Reply-To: <00af01c39112$d9ac4350$bf8ec6c1@flatline> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200310141009.26247.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/456 X-Sequence-Number: 4204 Ivan, > There was some talk, either on this list or freebsd-performance about > setting the default block size for PostgreSQL running on FreeBSD to be 16k > because of performance reasons. That is: *default* for the port, user is > not asked. So an automagical method to scale non-default block sizes is a > very needed thing. Hmmm ... possibly. My concern is that if someone uses a very non-default value, such as 256K, then they are probably better off doing their own tuning because they've got an unusual system. However, we could easily limit it to the range of 4K to 32K. Of course, since there's no GUC var, we'd have to ask the user to confirm their block size. I'm reluctant to take this approach because if the user gets it wrong, then the settings will be *way* off ... and possibly cause PostgreSQL to be unrunnable or have "out of memory" crashes. Unless there's a way to find it in the compiled source? > > 2) may not work well for anyone using unusual locales, optimization > > flags, or other non-default compile options except for language > > interfaces. > > Depends on what you consider 'unusual'? I hope not things like iso8859-x > (or, to be exact, European languages) :) On second thought, I'm not sure what an "unusual locale" would be. Scratch that. -- Josh Berkus Aglio Database Solutions San Francisco