To: azajac@ang.com.pl
cc: pgsql-performance@postgreSQL.org
Subject: Re: Problem with mergejoin performance 
In-reply-to: <005301cb5354$f0797100$d16c5300$@com.pl> 
References: <000001cb5307$78955480$69bffd80$@com.pl>
	<11777.1284387988@sss.pgh.pa.us>
	<005301cb5354$f0797100$d16c5300$@com.pl>
Comments: In-reply-to <azajac@ang.com.pl>
	message dated "Mon, 13 Sep 2010 17:04:17 +0200"
Date: Mon, 13 Sep 2010 11:16:40 -0400
Message-ID: <12711.1284391000@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

[ Please keep the list cc'd ]

<azajac@ang.com.pl> writes:
>> What exactly are those join key values, and what are the min/max values
>> in bug_t2?

> min of Bug_t1.id = 42,
> max of Bug_t1.id = 393065,
> min of Bug_t2.id = 352448,
> max of Bug_t2.id = 388715,

> select count(id) from bug_t2
> 	29
> select count(*) from bug_t2
> 	278417
> And because there is only 29 not null records in bug_t2:

Oh, that's the real problem: thousands of nulls in bug_t2.
The planner is thinking those don't have to be scanned, but
the executor wasn't on the same page until very recently:
http://archives.postgresql.org/pgsql-committers/2010-05/msg00334.php

That patch will be in the next 8.3 update.

			regards, tom lane