X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 3F09A52867 for ; Mon, 13 Jun 2005 18:18:54 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 37332-02 for ; Mon, 13 Jun 2005 21:18:49 +0000 (GMT) Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by svr1.postgresql.org (Postfix) with ESMTP id 0B98952809 for ; Mon, 13 Jun 2005 18:18:48 -0300 (ADT) Received: from [192.168.2.99] ([206.172.171.129]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050613211848.GXVH26102.tomts10-srv.bellnexxia.net@[192.168.2.99]>; Mon, 13 Jun 2005 17:18:48 -0400 Message-ID: <42ADF83B.1030706@alteeve.com> Date: Mon, 13 Jun 2005 17:18:51 -0400 From: Madison Kelly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: pgsql-performance@postgresql.org Cc: Tom Lane Subject: Pseudo-Solved was: (Re: Index ot being used) References: <42ACBC95.9020404@alteeve.com> <20050613030001.GB17491@wolff.to> <20050613031317.GA18988@wolff.to> <42AD008D.4080600@alteeve.com> <20050613035346.GA20703@wolff.to> <42AD0B94.9090508@alteeve.com> <20050613132852.GA31142@wolff.to> <42ADC77B.7000007@alteeve.com> <22127.1118686403@sss.pgh.pa.us> <42ADD8DC.1000001@alteeve.com> <20050613204559.GA1346@wolff.to> In-Reply-To: <20050613204559.GA1346@wolff.to> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200506/318 X-Sequence-Number: 12955 Bruno Wolff III wrote: > On Mon, Jun 13, 2005 at 15:05:00 -0400, > Madison Kelly wrote: > >>Wow! >> >>With the sequence scan off my query took less than 2sec. When I turned >>it back on the time jumped back up to just under 14sec. >> >> >>tle-bu=> set enable_seqscan = off; SET >>tle-bu=> EXPLAIN ANALYZE SELECT file_name, file_parent_dir, file_display >>FROM file_info_7 WHERE file_type='d' ORDER BY file_type ASC, >>file_parent_dir ASC, file_name ASC; >> >>QUERY PLAN >>-------------------------------------------------------------------------------------------------------------------------------------------------------- >> Index Scan using file_info_7_display_idx on file_info_7 >>(cost=0.00..83171.78 rows=25490 width=119) (actual >>time=141.405..1700.459 rows=25795 loops=1) >> Index Cond: ((file_type)::text = 'd'::text) >> Total runtime: 1851.366 ms >>(3 rows) >> >> >>tle-bu=> set enable_seqscan = on; SET >>tle-bu=> EXPLAIN ANALYZE SELECT file_name, file_parent_dir, file_display >>FROM file_info_7 WHERE file_type='d' ORDER BY file_type ASC, >>file_parent_dir ASC, file_name ASC; >> QUERY PLAN >>---------------------------------------------------------------------------------------------------------------------------- >> Sort (cost=14810.92..14874.65 rows=25490 width=119) (actual >>time=13605.185..13728.436 rows=25795 loops=1) >> Sort Key: file_type, file_parent_dir, file_name >> -> Seq Scan on file_info_7 (cost=0.00..11956.84 rows=25490 >>width=119) (actual time=0.048..2018.996 rows=25795 loops=1) >> Filter: ((file_type)::text = 'd'::text) >> Total runtime: 13865.830 ms >>(5 rows) >> >> So the index obiously provides a major performance boost! I just need >>to figure out how to tell the planner how to use it... > > > The two things you probably want to look at are (in postgresql.conf): > effective_cache_size = 10000 # typically 8KB each > random_page_cost = 2 # units are one sequential page fetch cost > > Increasing effective cache size and decreasing the penalty for random > disk fetches will favor using index scans. People have reported that > dropping random_page_cost from the default of 4 to 2 works well. > Effective cache size should be set to some reasonable estimate of > the memory available on your system to postgres, not counting that > set aside for shared buffers. > > However, since the planner thought the index scan plan was going to be 6 times > slower than the sequential scan plan, I don't know if tweaking these values > enough to switch the plan choice won't cause problems for other queries. Hmm, In this case I am trying to avoid modifying 'postgres.conf' and am trying to handle any performance tweaks within my program through SQL calls. This is because (I hope) my program will be installed by many users and I don't want to expect them to be able/comfortable playing with 'postgres.conf'. I do plan later though to create a section in the docs with extra tweaks for more advanced users and in that case I will come back to this and try/record just that. In the mean time Tom's recommendation works from perl by calling: $DB->do("SET ENABLE_SEQSCAN TO OFF") || die... $DB->do("SET ENABLE_SEQSCAN TO ON") || die... Forces the index to be used. It isn't clean but it works for now and I don't need to do anything outside my program. Lacking any other ideas, thank you very, very much for sticking with this and helping me out! Madison -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Madison Kelly (Digimer) TLE-BU, The Linux Experience; Back Up http://tle-bu.thelinuxexperience.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-