Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 71FAD2E0063 for ; Sun, 27 Apr 2008 22:54:17 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 56352-01 for ; Sun, 27 Apr 2008 22:54:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from dc.baikal.ru (dc.baikal.ru [212.176.3.237]) by developer.postgresql.org (Postfix) with ESMTP id 270FC2E005C for ; Sun, 27 Apr 2008 22:54:13 -0300 (ADT) Received: from it319k5.dc-local (it319k5.dc-local [10.0.4.75]) (authenticated bits=0) by dc.baikal.ru (8.13.8/8.13.8) with ESMTP id m3S1pbfH007238; Mon, 28 Apr 2008 10:51:38 +0900 Message-ID: <48152DAA.8080206@dc.baikal.ru> Date: Mon, 28 Apr 2008 10:51:38 +0900 From: Vlad Arkhipov User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: PFC CC: pgsql-performance@postgresql.org Subject: Re: Optimizer's issue References: <480FDF0E.3000909@dc.baikal.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on dc.baikal.ru X-Virus-Status: Clean X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=AWL=0.000 X-Spam-Level: X-Archive-Number: 200804/384 X-Sequence-Number: 29877 PFC пишет: > 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 = g.id >> where g.isgroup >> >> Hash Join (cost=5.35..11.50 rows=11 width=25) (actual time=0.261..1.755 >> rows=294 loops=1) >> Hash Cond: (a.groupid = g.id) >> -> Seq Scan on a (cost=0.00..4.94 rows=294 width=16) (actual >> time=0.047..0.482 rows=294 loops=1) >> -> Hash (cost=5.20..5.20 rows=12 width=9) (actual time=0.164..0.164 >> rows=12 loops=1) >> -> Seq Scan on g (cost=0.00..5.20 rows=12 width=9) (actual >> time=0.042..0.136 rows=12 loops=1) >> 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... > > > I redesigned tables structure and the query seems to be become faster. You was right, the problem was not in this query.