To: Svetlin Manavski <svetlin.manavski@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Unexpected seq scans when expected result is 1 row out of milions
In-reply-to: 
 <CAMm+ggR=-+pqw9Qo7uQ6dx9pa0bUfBEXz6z-+UfUNGvRuJuBXA@mail.gmail.com>
References: 
 <CAMm+ggR=-+pqw9Qo7uQ6dx9pa0bUfBEXz6z-+UfUNGvRuJuBXA@mail.gmail.com>
Comments: In-reply-to Svetlin Manavski <svetlin.manavski@gmail.com>
	message dated "Fri, 15 Jul 2011 13:57:18 +0100"
Date: Fri, 15 Jul 2011 13:58:49 -0400
Message-ID: <4223.1310752729@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Svetlin Manavski <svetlin.manavski@gmail.com> writes:
> The question is: why do we get a seq scan on appqosdata.tcpsessiondata_1 and
> appqosdata.tcpsessiondata_2 even if the planner estimates correctly 1 row
> out of millions could potentially be selected? As you can see ~90% of the
> time is spent on those 2 partitions even if they are not apparently
> different from any of the others.

Well, there must be *something* different about them.  Are you sure
they've got the same indexes as the others?  It would be useful to see
psql's \d report for those partitions, as well as for one of the
partitions that's behaving as expected.  You might also compare the
EXPLAIN results for doing the query on just one child table between
the normal and misbehaving partitions.

			regards, tom lane