Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 944BB6322BB
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon,  9 Mar 2009 20:36:20 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 41586-04
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon,  9 Mar 2009 20:36:08 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id D2CF262DDA8
	for <pgsql-performance@postgresql.org>;
	Mon,  9 Mar 2009 20:36:13 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n29NaAUJ017870;
	Mon, 9 Mar 2009 19:36:11 -0400 (EDT)
To: Mario Splivalo <mario.splivalo@megafon.hr>
cc: pgsql-performance@postgresql.org
Subject: Re: Query much slower when run from postgres function 
In-reply-to: <49B5948C.3050800@megafon.hr> 
References: <49B51B60.6030600@megafon.hr> <27649.1236616294@sss.pgh.pa.us>
	<49B56A3D.8000100@megafon.hr> <14317.1236628318@sss.pgh.pa.us>
	<49B5948C.3050800@megafon.hr>
Comments: In-reply-to Mario Splivalo <mario.splivalo@megafon.hr>
	message dated "Mon, 09 Mar 2009 23:13:32 +0100"
Date: Mon, 09 Mar 2009 19:36:10 -0400
Message-ID: <17869.1236641770@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200903/74
X-Sequence-Number: 32996

Mario Splivalo <mario.splivalo@megafon.hr> writes:
> So, it is the same. When I do EXPLAIN ANALYZE EXECUTE I get completely
> different execution plan:
> ...
>                      ->  Bitmap Heap Scan on messages
> (cost=287.98..21192.42 rows=12848 width=4) (actual time=0.049..0.169
> rows=62 loops=1)
>                            Recheck Cond: (service_id = $1)
>                            ->  Bitmap Index Scan on
> messages_uq__service_id__tan  (cost=0.00..284.77 rows=12848 width=0)
> (actual time=0.038..0.038 rows=62 loops=1)
>                                  Index Cond: (service_id = $1)

Well, there's the problem: without knowing what the specific service_id
is, the planner is estimating 12848 matching rows, which is evidently
off by a couple of orders of magnitude.  And that's pushing it to adopt
a hash join instead of a nestloop.  Are you sure the stats on this
table are up to date?  Maybe you need to increase the stats target?

			regards, tom lane