Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id CA8542E0039 for ; Tue, 6 May 2008 12:27:47 -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 55661-06 for ; Tue, 6 May 2008 12:27:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from gatefox.foxi.nl (foxi.xs4all.nl [194.109.246.192]) by developer.postgresql.org (Postfix) with ESMTP id 6843C2E002D for ; Tue, 6 May 2008 12:27:44 -0300 (ADT) Received: from techfox.foxi (techfox.foxi [192.168.0.79]) by gatefox.foxi.nl (8.13.7/8.13.7) with ESMTP id m46FRg5W015388; Tue, 6 May 2008 17:27:42 +0200 From: Frank van Vugt Organization: Foxi Consultants in Technology BV To: pgsql-performance@postgresql.org, Tom Lane Subject: Re: plan difference between set-returning function with ROWS within IN() and a plain join Date: Tue, 6 May 2008 17:27:40 +0200 User-Agent: KMail/1.9.5 References: <200805061021.43448.ftm.van.vugt@foxi.nl> <13551.1210083430@sss.pgh.pa.us> In-Reply-To: <13551.1210083430@sss.pgh.pa.us> X-message-flag: Fed up with inflexible software? Worried about this kind of behaviour? Have us explain Linux! Greetings from Foxi C.i.T. BV MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805061727.41210.ftm.van.vugt@foxi.nl> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.082 tagged_above=0 required=5 tests=AWL=0.082 X-Spam-Level: X-Archive-Number: 200805/80 X-Sequence-Number: 30048 > > db=# explain analyse > > select sum(base_total_val) > > from sales_invoice > > where id in (select id from si_credit_tree(80500007)); > > Did you check whether this query even gives the right answer? You knew the right answer to that already ;) > I think you forgot the alias foo(id) in the subselect and it's > actually reducing to "where id in (id)", ie, TRUE. Tricky, but completely obvious once pointed out, that's _exactly_ what was happening. db=# explain analyse select sum(base_total_val) from sales_invoice where id in (select id from si_credit_tree(80500007) foo(id)); QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=42.79..42.80 rows=1 width=8) (actual time=0.440..0.441 rows=1 loops=1) -> Nested Loop (cost=1.31..42.77 rows=5 width=8) (actual time=0.346..0.413 rows=5 loops=1) -> HashAggregate (cost=1.31..1.36 rows=5 width=4) (actual time=0.327..0.335 rows=5 loops=1) -> Function Scan on si_credit_tree foo (cost=0.00..1.30 rows=5 width=4) (actual time=0.300..0.306 rows=5 loops=1) -> Index Scan using sales_invoice_pkey on sales_invoice (cost=0.00..8.27 rows=1 width=12) (actual time=0.006..0.008 rows=1 loops=5) Index Cond: (sales_invoice.id = foo.id) Total runtime: 0.559 ms Thanks for the replies! -- Best, Frank.