Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 936D62E0061 for ; Thu, 24 Apr 2008 13:20:03 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 02451-07 for ; Thu, 24 Apr 2008 13:19:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by developer.postgresql.org (Postfix) with SMTP id 990622E0055 for ; Thu, 24 Apr 2008 13:19:54 -0300 (ADT) Received: (qmail 17727 invoked by uid 503); 24 Apr 2008 18:06:40 -0000 Received: from gw2.ovh.net (HELO mail174.ha.ovh.net) (213.251.189.202) by 27.mail-out.ovh.net with SMTP; 24 Apr 2008 18:06:40 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 24 Apr 2008 16:19:51 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13.peufeu.com) (88.161.102.87) by ns0.ovh.net with SMTP; 24 Apr 2008 16:19:49 -0000 Date: Thu, 24 Apr 2008 18:24:50 +0200 To: "Vlad Arkhipov" , pgsql-performance@postgresql.org Subject: Re: Optimizer's issue From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <480FDF0E.3000909@dc.baikal.ru> Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: <480FDF0E.3000909@dc.baikal.ru> User-Agent: Opera Mail/9.24 (Linux) X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N X-Ovh-Tracer-Id: 14713259983866037808 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.724 tagged_above=0 required=5 tests=AWL=0.724 X-Spam-Level: X-Archive-Number: 200804/360 X-Sequence-Number: 29853 On Thu, 24 Apr 2008 03:14:54 +0200, Vlad Arkhipov = = wrote: > I found strange issue in very simple query. Statistics for all columns= > is on the level 1000 but I also tried other levels. > > create table g ( > id bigint primary key, > isgroup boolean not null); > > create table a ( > groupid bigint references g(id), > id bigint, > unique(id, groupid)); > > analyze g; > analyze a; > > select count(*) from a > 294 > > select count(*) from g > 320 > > explain analyze > select * > from g > join a on a.groupid =3D g.id > where g.isgroup > > Hash Join (cost=3D5.35..11.50 rows=3D11 width=3D25) (actual time=3D0.= 261..1.755 > rows=3D294 loops=3D1) > Hash Cond: (a.groupid =3D g.id) > -> Seq Scan on a (cost=3D0.00..4.94 rows=3D294 width=3D16) (actual= > time=3D0.047..0.482 rows=3D294 loops=3D1) > -> Hash (cost=3D5.20..5.20 rows=3D12 width=3D9) (actual time=3D0.1= 64..0.164 > rows=3D12 loops=3D1) > -> Seq Scan on g (cost=3D0.00..5.20 rows=3D12 width=3D9) (ac= tual > time=3D0.042..0.136 rows=3D12 loops=3D1) > Filter: isgroup > Total runtime: 2.225 ms You should really put an EXPLAIN ANALYZE of your big query. This little query plan seems OK to me. Two very small tables, ok, hash'em, it's the best. Now, of course if it is repeated for every row in your JOIN, you have a= = problem. The question is, why is it repeated for every row ? This cannot be answered without seeing the whole query. Another question would be, is there a way to structure the tables = differently ? Again, this cannot be answered without seeing the whole query, and some= = explanation about what the data & fields mean. Please provide more information...