X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 94CABDA127; Wed, 19 Oct 2005 11:52:11 -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 28517-03; Wed, 19 Oct 2005 14:52:05 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id BE6F3D8379; Wed, 19 Oct 2005 11:52:07 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 3CB4C31059; Wed, 19 Oct 2005 16:52:12 +0200 (MET DST) From: Katherine Stoovs X-Newsgroups: pgsql.hackers, pgsql.performance Subject: tuning seqscan costs Followup-To: pgsql.hackers Date: Wed, 19 Oct 2005 14:51:55 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 29 Message-ID: X-Complaints-To: abuse@aioe.org User-Agent: slrn/0.9.8.1pl1 (Linux) To: pgsql-hackers@postgresql.org, pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200510/343 X-Sequence-Number: 15111 I want to correlate two index rows of different tables to find an offset so that table1.value = table2.value AND table1.id = table2.id + offset is true for a maximum number of rows. To achieve this, I have the two tables and a table with possible offset values and execute a query: SELECT value,(SELECT COUNT(*) FROM table1,table2 WHERE table1.value = table2.value AND table1.id = table2.id + offset) AS matches FROM offsets ORDER BY matches; The query is very inefficient, however, because the planner doesn't use my indexes and executes seqscans instead. I can get it to execute fast by setting ENABLE_SEQSCAN to OFF, but I have read this will make the performance bad on other query types so I want to know how to tweak the planner costs or possibly other stats so the planner will plan the query correctly and use index scans. There must be something wrong in the planning parameters after all if a plan that is slower by a factor of tens or hundreds becomes estimated better than the fast variant. I have already issued ANALYZE commands on the tables. Thanks for your help, Katherine Stoovs