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 DDE55D6E69 for ; Thu, 22 Sep 2005 19:54:42 -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 44407-01 for ; Thu, 22 Sep 2005 22:54:39 +0000 (GMT) Received: from tigger.fuhr.org (tigger.fuhr.org [63.214.45.158]) by svr1.postgresql.org (Postfix) with ESMTP id 430E6D76BA for ; Thu, 22 Sep 2005 19:54:39 -0300 (ADT) Received: from winnie.fuhr.org (winnie.fuhr.org [10.1.0.1]) by tigger.fuhr.org (8.13.3/8.13.3) with ESMTP id j8MMsXI2057410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2005 16:54:36 -0600 (MDT) (envelope-from mfuhr@winnie.fuhr.org) Received: from winnie.fuhr.org (localhost [127.0.0.1]) by winnie.fuhr.org (8.13.3/8.13.3) with ESMTP id j8MMsXiC025145; Thu, 22 Sep 2005 16:54:33 -0600 (MDT) (envelope-from mfuhr@winnie.fuhr.org) Received: (from mfuhr@localhost) by winnie.fuhr.org (8.13.3/8.13.3/Submit) id j8MMsXoX025144; Thu, 22 Sep 2005 16:54:33 -0600 (MDT) (envelope-from mfuhr) Date: Thu, 22 Sep 2005 16:54:32 -0600 From: Michael Fuhr To: Josh Berkus Cc: pgsql-performance@postgresql.org, Jean-Pierre Pelletier , John Arbash Meinel Subject: Re: Queries 15 times slower on 8.1 beta 2 than on 8.0 Message-ID: <20050922225432.GA25103@winnie.fuhr.org> References: <433326A6.8010708@arbash-meinel.com> <200509221519.05555.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509221519.05555.josh@agliodbs.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.005 required=5 tests=[AWL=0.005] X-Spam-Level: X-Archive-Number: 200509/259 X-Sequence-Number: 14567 On Thu, Sep 22, 2005 at 03:19:05PM -0700, Josh Berkus wrote: > > " -> Seq Scan on price p (cost=0.00..11317.75 rows=581475 width=4) > > (actual time=0.004..1143.720 rows=581475 loops=1)" > > Well, this is your pain point. Can we see the index scan plan on 8.1? > Given that it's *expecting* only one row, I can't understand why it's > using a seq scan ... I've created a simplified, self-contained test case for this: CREATE TABLE price ( priceid integer PRIMARY KEY ); CREATE TABLE supplier ( supplierid integer PRIMARY KEY ); CREATE TABLE content ( contentid integer PRIMARY KEY, supplierid integer NOT NULL REFERENCES supplier, priceid integer NOT NULL REFERENCES price ); INSERT INTO price (priceid) SELECT * FROM generate_series(1, 50000); INSERT INTO supplier (supplierid) SELECT * FROM generate_series(1, 10000); INSERT INTO content (contentid, supplierid, priceid) VALUES (1, 1, 50000); ANALYZE price; ANALYZE supplier; ANALYZE content; EXPLAIN ANALYZE SELECT 0 FROM content c LEFT OUTER JOIN supplier s ON c.supplierid = s.supplierid LEFT OUTER JOIN price p ON c.priceid = p.priceid; Here's the EXPLAIN ANALYZE from 8.0.3: Nested Loop Left Join (cost=0.00..7.06 rows=1 width=0) (actual time=0.180..0.232 rows=1 loops=1) -> Nested Loop Left Join (cost=0.00..4.04 rows=1 width=4) (actual time=0.105..0.133 rows=1 loops=1) -> Seq Scan on content c (cost=0.00..1.01 rows=1 width=8) (actual time=0.021..0.029 rows=1 loops=1) -> Index Scan using supplier_pkey on supplier s (cost=0.00..3.01 rows=1 width=4) (actual time=0.052..0.059 rows=1 loops=1) Index Cond: ("outer".supplierid = s.supplierid) -> Index Scan using price_pkey on price p (cost=0.00..3.01 rows=1 width=4) (actual time=0.046..0.055 rows=1 loops=1) Index Cond: ("outer".priceid = p.priceid) Total runtime: 0.582 ms Here it is from 8.1beta2: Merge Right Join (cost=4.05..1054.06 rows=1 width=0) (actual time=676.863..676.895 rows=1 loops=1) Merge Cond: ("outer".priceid = "inner".priceid) -> Index Scan using price_pkey on price p (cost=0.00..925.00 rows=50000 width=4) (actual time=0.035..383.345 rows=50000 loops=1) -> Sort (cost=4.05..4.05 rows=1 width=4) (actual time=0.152..0.159 rows=1 loops=1) Sort Key: c.priceid -> Nested Loop Left Join (cost=0.00..4.04 rows=1 width=4) (actual time=0.082..0.111 rows=1 loops=1) -> Seq Scan on content c (cost=0.00..1.01 rows=1 width=8) (actual time=0.016..0.024 rows=1 loops=1) -> Index Scan using supplier_pkey on supplier s (cost=0.00..3.01 rows=1 width=4) (actual time=0.039..0.047 rows=1 loops=1) Index Cond: ("outer".supplierid = s.supplierid) Total runtime: 677.563 ms If we change content's priceid then we get the same plan but faster results: UPDATE content SET priceid = 1; Merge Right Join (cost=4.05..1054.06 rows=1 width=0) (actual time=0.268..0.303 rows=1 loops=1) Merge Cond: ("outer".priceid = "inner".priceid) -> Index Scan using price_pkey on price p (cost=0.00..925.00 rows=50000 width=4) (actual time=0.049..0.061 rows=2 loops=1) -> Sort (cost=4.05..4.05 rows=1 width=4) (actual time=0.187..0.192 rows=1 loops=1) Sort Key: c.priceid -> Nested Loop Left Join (cost=0.00..4.04 rows=1 width=4) (actual time=0.099..0.128 rows=1 loops=1) -> Seq Scan on content c (cost=0.00..1.01 rows=1 width=8) (actual time=0.025..0.033 rows=1 loops=1) -> Index Scan using supplier_pkey on supplier s (cost=0.00..3.01 rows=1 width=4) (actual time=0.046..0.053 rows=1 loops=1) Index Cond: ("outer".supplierid = s.supplierid) Total runtime: 0.703 ms -- Michael Fuhr