Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 19B972E46E0 for ; Sun, 20 Jan 2008 14:37:33 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 01712-03-2 for ; Sun, 20 Jan 2008 14:37:28 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id E34DF2E2E99 for ; Sun, 20 Jan 2008 14:30:39 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id m0KIUZXI010406; Sun, 20 Jan 2008 13:30:36 -0500 (EST) To: "Merlin Moncure" cc: "Heikki Linnakangas" , "Dean Rasheed" , pgsql-performance@postgresql.org Subject: Re: Slow set-returning functions In-reply-to: References: <47935C0C.4090908@enterprisedb.com> Comments: In-reply-to "Merlin Moncure" message dated "Sun, 20 Jan 2008 10:25:48 -0500" Date: Sun, 20 Jan 2008 13:30:35 -0500 Message-ID: <10405.1200853835@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/156 X-Sequence-Number: 28395 "Merlin Moncure" writes: > prepared statements have the same problem. IIRC the planner assumes > 10%, which will often drop to a seqscan or a bitmap index scan. Some > years back I argued (unsuccessfully) to have the planner guess 100 > rows or something like that. Ideally, I think it would generate the > plan from the value passed into the first invocation of the function. I believe it's the case that that will happen now in the same contexts where the planner uses the first value of any other parameter (ie, unnamed statements in the extended-query protocol). regards, tom lane