Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 66E7164FD47 for ; Sun, 23 Nov 2008 04:10:32 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 62407-02 for ; Sun, 23 Nov 2008 04:10:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 137086.vserver.de (static-ip-62-75-137-86.inaddr.intergenia.de [62.75.137.86]) by mail.postgresql.org (Postfix) with ESMTP id A100F64FCDD for ; Sun, 23 Nov 2008 04:10:27 -0400 (AST) Received: from a-kretschmer.de (p54B381C5.dip0.t-ipconnect.de [84.179.129.197]) (authenticated bits=0) by 137086.vserver.de (8.12.8/8.12.8) with ESMTP id mAN8APrZ029967 for ; Sun, 23 Nov 2008 09:10:25 +0100 Received: from kretschmer by a-kretschmer.de with local (Exim 4.69) (envelope-from ) id 1L4A2y-0001xP-Sw for pgsql-performance@postgresql.org; Sun, 23 Nov 2008 09:10:24 +0100 Date: Sun, 23 Nov 2008 09:10:24 +0100 From: Andreas Kretschmer To: pgsql-performance@postgresql.org Subject: Re: seq scan over 3.3 million rows instead of single key index access Message-ID: <20081123081024.GA7443@tux> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-OS: Debian/GNU Linux - weil ich es mir Wert bin! X-GPG-Fingerprint: EE16 3C01 7B9C 10F7 2C8B 3B86 4DB3 D9EE 7F45 84DA X-Message-Flag: "Windows" is not the answer. "Windows" is the question and the answer is "no"! X-Lugdd: Gerd Kube X-Info: My name is root. Just root. And I am licensed to kill -9 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/213 X-Sequence-Number: 31944 Andrus schrieb: > There are indexes on rid(dokumnr) and dok(dokumnr) and dokumnr is int. > Instead of using single key index, 8.1.4 scans over whole rid table. > Sometimes idtelluued can contain more than single row so replacing join > with equality is not possible. > > How to fix ? > > Andrus. > > CREATE TEMP TABLE idtellUued(dokumnr INT) ON COMMIT DROP; > INSERT INTO idtellUued VALUES(1249228); > explain analyze select 1 > from dok JOIN rid USING(dokumnr) > JOIN idtellUued USING(dokumnr) > > "Hash Join (cost=7483.22..222259.77 rows=5706 width=0) (actual > time=14905.981..27065.903 rows=8 loops=1)" > " Hash Cond: ("outer".dokumnr = "inner".dokumnr)" > " -> Seq Scan on rid (cost=0.00..198240.33 rows=3295833 width=4) > (actual time=0.036..15021.641 rows=3280576 loops=1)" How many rows contains rid? The estimation are okay, rows=3295833 and actual rows=3280576 are nearly identical. An index-scan makes only sense if rid contains considerable more than 3000000 rows. Andreas -- Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) "If I was god, I would recompile penguin with --enable-fly." (unknown) Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°