X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 799A89DCD22 for ; Mon, 12 Dec 2005 09:09:49 -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 92140-03 for ; Mon, 12 Dec 2005 09:09:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtp1.iitb.ac.in (unknown [202.68.145.249]) by postgresql.org (Postfix) with SMTP id F356D9DCD1E for ; Mon, 12 Dec 2005 09:09:43 -0400 (AST) Received: (qmail 30009 invoked from network); 12 Dec 2005 18:39:43 +0530 Received: from unknown (HELO ldns2.iitb.ac.in) (10.200.12.2) by smtp1.iitb.ac.in with SMTP; 12 Dec 2005 18:39:43 +0530 Received: (qmail 13074 invoked by uid 509); 12 Dec 2005 13:09:43 -0000 Received: from 10.105.1.1 by ldns2 (envelope-from , uid 501) with qmail-scanner-1.25st (clamdscan: 0.87.1/1207. spamassassin: 3.1.0. Clear:RC:1(10.105.1.1):. Processed in 0.023752 secs); 12 Dec 2005 13:09:43 -0000 Received: from unknown (HELO cse.iitb.ac.in) (10.105.1.1) by ldns2.iitb.ac.in with SMTP; 12 Dec 2005 13:09:43 -0000 Received: (qmail 13956 invoked by uid 11940); 12 Dec 2005 13:10:12 -0000 Received: from 10.105.11.33 by jeeves.cse.iitb.ac.in (envelope-from , uid 11926) with qmail-scanner-1.25 (clamdscan: 0.87/1207. spamassassin: 3.1.0. Clear:RC:1(10.105.11.33):. Processed in 0.028781 secs); 12 Dec 2005 13:10:12 -0000 Received: from nsl-33.cse.iitb.ac.in ([10.105.11.33]) (envelope-sender ) by cse.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 12 Dec 2005 13:10:12 -0000 Date: Mon, 12 Dec 2005 18:39:42 +0530 (IST) From: "Anjan Kumar. A." To: pgsql-hackers@postgresql.org Subject: Re: Please Help: PostgreSQL Query Optimizer In-Reply-To: <17378.1134321553@sss.pgh.pa.us> Message-ID: References: <17378.1134321553@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.323 required=5 tests=[AWL=-0.156, DNS_FROM_RFC_ABUSE=0.479] X-Spam-Score: 0.323 X-Spam-Level: X-Archive-Number: 200512/587 X-Sequence-Number: 77435 Defaulat values of various parameters in PostgreSQL: #random_page_cost = 4 # units are one sequential page fetch cost #cpu_tuple_cost = 0.01 # (same) #cpu_index_tuple_cost = 0.001 # (same) #cpu_operator_cost = 0.0025 # (same) #effective_cache_size = 1000 # typically 8KB each Since sequential access is not significantly faster than random access in a MMDB, random_page_cost will be approximately same as sequential page fetch cost. If we make both sequential_page_fetch_cost and random_page_cost to "1", then we need to increase the various cpu_* paramters by multiplying the default values with appropriate "Scaling Factor". Now, we need to determine this Scaling Factor. Through googling, i found that Normal Disk has external data transfer rate of around 40MBps, where as Main Memory has Data transfer rate ranging from 1.6GBps to 2.8GBps. As we can see, the ratio between Disk and Main Memory data transfer rates is around 50. Then, if we multiply all cpu_* paramters by 50, the resulting values will be: random_page_cost = 1; cpu_tuple_cost = 0.5; cpu_index_tuple_cost = 0.05; cpu_operator_cost = 0.0125; Would it be a suitable approach ? We request all of u to give comments/suggestions on this calcualations. Thanking You. On Sun, 11 Dec 2005, Tom Lane wrote: > [ trimming cc list to something sane ] > > "Anjan Kumar. A." writes: >> In Main Memory DataBase(MMDB) entire database on the disk is loaded on to the main memory during initial startup of the system. There after all the references are made to database on the main memory. When the system is going to shutdown, we will write back the database on the main memory to disk. Here, for the sake of recovery we are writing log records on to the disk during the transaction execution. > > Don't you get 99.9% of this for free with Postgres' normal behavior? > Just increase shared_buffers. > >> Can any one tell me the modifications needs to be incorporated to PostgreSQL, so that it considers only Processing Costs during optimization of the Query. > > Assuming that a page fetch costs zero is wrong even in an all-in-memory > environment. So I don't see any reason you can't maintain the > convention that a page fetch costs 1.0 unit, and just adjust the other > cost parameters in the light of a different idea about what that > actually means. > >> 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; >> cpu_tuple_cost = 2; >> cpu_index_tuple_cost = 0.2; >> cpu_operator_cost = 0.05; > > You'd want random_page_cost = 1 since there is presumably no penalty for > random access in this context. Also, I think you'd want > cpu_operator_cost a lot higher than that (maybe you dropped a decimal > place? You scaled the others up by 200 but this one only by 20). > > It's entirely possible that the ratios of the cpu_xxx_cost values > aren't very good and will need work. In the past we've never had > occasion to study them very carefully, since they were only marginal > contributions anyway. > > regards, tom lane > -- Regards. Anjan Kumar A. MTech2, Comp Sci., www.cse.iitb.ac.in/~anjankumar ______________________________________________________________ A woman physician has made the statement that smoking is neither physically defective nor morally degrading, and that nicotine, even when indulged to in excess, is less harmful than excessive petting." -- Purdue Exponent, Jan 16, 1925