X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id A489A550E6 for ; Tue, 8 Mar 2005 18:35:50 +0000 (GMT) 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 55985-07 for ; Tue, 8 Mar 2005 18:35:48 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.250.190.2]) by svr1.postgresql.org (Postfix) with ESMTP id 1CE7055012 for ; Tue, 8 Mar 2005 18:35:47 +0000 (GMT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id D318632033; Tue, 8 Mar 2005 19:35:46 +0100 (MET) From: Gaetano Mendola X-Newsgroups: pgsql.performance Subject: Re: bad plan Date: Tue, 08 Mar 2005 19:35:31 +0100 Organization: Hub.Org Networking Services Lines: 96 Message-ID: <422DF073.7080307@bigfoot.com> References: <422D7F23.7000109@bigfoot.com> <422D8F0E.8000906@archonet.com> <422D9904.5010904@bigfoot.com> <422DA6A5.2060908@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org To: Richard Huxton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en In-Reply-To: <422DA6A5.2060908@archonet.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.004 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200503/131 X-Sequence-Number: 10836 Richard Huxton wrote: > OK, so looking at the original EXPLAIN the order of processing seems to be: > 1. v_sat_request is evaluated and filtered on login='...' (lines 7..15) > This gives us 31 rows > 2. The left-join from v_sat_request to v_sc_packages is processed (lines > 5..6) > This involves the subquery scan on vsp (from line 16) where it seems to > think the best idea is a merge join of programs to sequences. Whel basically v_sc_packages depends on other 3 views that are just a simple interface to a plain table. If I execute a select only on this table I get reasonable executions time: === cpu_tuple_cost = 0.07 # explain analyze select * from v_sc_packages where id_package = 19628; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- Nested Loop (cost=0.00..15.96 rows=1 width=131) (actual time=41.450..41.494 rows=1 loops=1) -> Nested Loop (cost=0.00..11.86 rows=1 width=116) (actual time=1.022..1.055 rows=1 loops=1) -> Nested Loop Left Join (cost=0.00..7.89 rows=1 width=104) (actual time=0.330..0.345 rows=1 loops=1) -> Index Scan using packages_pkey on packages p (cost=0.00..3.90 rows=1 width=104) (actual time=0.070..0.075 rows=1 loops=1) Index Cond: (id_package = 19628) -> Index Scan using package_security_id_package_key on package_security ps (cost=0.00..3.91 rows=1 width=4) (actual time=0.232..0.237 rows=1 loops=1) Index Cond: ("outer".id_package = ps.id_package) -> Index Scan using idx_sequences_id_package on sequences (cost=0.00..3.90 rows=1 width=16) (actual time=0.670..0.685 rows=1 loops=1) Index Cond: (19628 = id_package) Filter: (estimated_start IS NOT NULL) -> Index Scan using programs_pkey on programs (cost=0.00..4.02 rows=1 width=19) (actual time=0.078..0.086 rows=1 loops=1) Index Cond: (programs.id_program = "outer".id_program) Filter: (id_program <> 0) Total runtime: 42.650 ms (14 rows) === cpu_tuple_cost = 0.01 # explain analyze select * from v_sc_packages where id_package = 19628; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Nested Loop (cost=0.00..15.54 rows=1 width=131) (actual time=25.062..69.977 rows=1 loops=1) -> Nested Loop (cost=0.00..11.56 rows=1 width=116) (actual time=5.396..50.299 rows=1 loops=1) -> Nested Loop Left Join (cost=0.00..7.71 rows=1 width=104) (actual time=5.223..32.842 rows=1 loops=1) -> Index Scan using packages_pkey on packages p (cost=0.00..3.84 rows=1 width=104) (actual time=0.815..7.235 rows=1 loops=1) Index Cond: (id_package = 19628) -> Index Scan using package_security_id_package_key on package_security ps (cost=0.00..3.85 rows=1 width=4) (actual time=4.366..25.555 rows=1 loops=1) Index Cond: ("outer".id_package = ps.id_package) -> Index Scan using idx_sequences_id_package on sequences (cost=0.00..3.84 rows=1 width=16) (actual time=0.147..17.422 rows=1 loops=1) Index Cond: (19628 = id_package) Filter: (estimated_start IS NOT NULL) -> Index Scan using programs_pkey on programs (cost=0.00..3.96 rows=1 width=19) (actual time=0.043..0.049 rows=1 loops=1) Index Cond: (programs.id_program = "outer".id_program) Filter: (id_program <> 0) Total runtime: 70.254 ms (14 rows) and I get the best with this: === cpu_tuple_cost = 0.001 # explain analyze select * from v_sc_packages where id_package = 19628; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Nested Loop (cost=0.00..15.48 rows=1 width=131) (actual time=2.516..2.553 rows=1 loops=1) -> Nested Loop (cost=0.00..7.78 rows=1 width=31) (actual time=1.439..1.457 rows=1 loops=1) -> Index Scan using idx_sequences_id_package on sequences (cost=0.00..3.83 rows=1 width=16) (actual time=0.442..0.450 rows=1 loops=1) Index Cond: (19628 = id_package) Filter: (estimated_start IS NOT NULL) -> Index Scan using programs_pkey on programs (cost=0.00..3.95 rows=1 width=19) (actual time=0.972..0.978 rows=1 loops=1) Index Cond: (programs.id_program = "outer".id_program) Filter: (id_program <> 0) -> Nested Loop Left Join (cost=0.00..7.68 rows=1 width=104) (actual time=0.110..0.125 rows=1 loops=1) -> Index Scan using packages_pkey on packages p (cost=0.00..3.84 rows=1 width=104) (actual time=0.040..0.046 rows=1 loops=1) Index Cond: (id_package = 19628) -> Index Scan using package_security_id_package_key on package_security ps (cost=0.00..3.84 rows=1 width=4) (actual time=0.036..0.042 rows=1 loops=1) Index Cond: ("outer".id_package = ps.id_package) Total runtime: 2.878 ms (14 rows) but with this last setting for the original query is choosed a very bad plan. Regards Gaetano Mendola