X-Original-To: pgsql-benchmarks-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 8861A9DCCFC; Sun, 11 Dec 2005 15:25:29 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 21084-05; Sun, 11 Dec 2005 15:25:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id 0DF4B9DCCE5; Sun, 11 Dec 2005 15:25:26 -0400 (AST) X-EthosMedia-Virus-Scanned: no infections found Received: from [63.195.55.98] (account josh@agliodbs.com HELO spooky) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 8675371; Sun, 11 Dec 2005 11:28:04 -0800 From: Josh Berkus Organization: Aglio Database Solutions To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Please Help: PostgreSQL Query Optimizer Date: Sun, 11 Dec 2005 11:26:18 -0800 User-Agent: KMail/1.8 Cc: "Anjan Kumar. A." , pgsql-chat@postgresql.org, pgsql-benchmarks@postgresql.org, pgsql-docs@postgresql.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512111126.18566.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/4 X-Sequence-Number: 50 Anjan, > In our case we are reading pages from Main Memory File System, but not from > Disk. Will it be sufficient, if we change the default values of above > paramters in "src/include/optimizer/cost.h and > src/backend/utils/misc/postgresql.conf.sample" as follows: > > random_page_cost = 4; This should be dramatically lowered. It's supposed to represent the ratio of seek-fetches to seq scans on disk. Since there's no disk, it should be a flat 1.0. However, we are aware that there are flaws in our calculations involving random_page_cost, such that the actual number for a system where there is no disk cost would be lower than 1.0. Your research will hopefully help us find these flaws. > cpu_tuple_cost = 2; > cpu_index_tuple_cost = 0.2; > cpu_operator_cost = 0.05; I don't see why you're increasing the various cpu_* costs. CPU costs would be unaffected by the database being in memory. In general, I lower these by a divisor based on the cpu speed; for example, on a dual-opteron system I lower the defaults by /6. However, that's completely unrelated to using an MMDB. So, other than random_page_cost, I don't know of other existing GUCs that would be directly related to using a disk/not using a disk. How are you handling shared memory and work memory? I look forward to hearing more about your test! -- Josh Berkus Aglio Database Solutions San Francisco