Message-ID: <4C484874.3060609@2ndquadrant.com>
Date: Thu, 22 Jul 2010 09:32:36 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Philippe Rimbault <primbault@edd.fr>
CC: pgsql-performance@postgresql.org
Subject: Re: Strange explain on partitioned tables
References: <4C47F8C8.10005@edd.fr>
In-Reply-To: <4C47F8C8.10005@edd.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Philippe Rimbault wrote:
> I have one thousand inherited tables like this one (with a different 
> check constraint on each) :

The PostgreSQL partitioning system is aimed to support perhaps a hundred 
inherited tables.  You can expect to get poor performance on queries if 
you create 1000 of them.  That's not the cause of your current problem, 
just pointing out there's a larger design problem here you'll probably 
have to fix one day.

> EXPLAIN ANALYZE
>     select
>         documents.id,
>         documents.num,
>         sources.name,
>         l.name
>     from
>         documents,
>         locations l,
>         sources
>     where
>         documents.id_source = 113 and
>         documents.id_location=l.id and
>         documents.id_source=sources.id
>     order by
>         documents.id desc
>     limit 5;

Please don't put your EXPLAIN plans surrounded in " marks; it makes it 
harder to copy out of your message to analyze them with tools.  I put 
this bad one into http://explain.depesz.com/s/XD and it notes that the 
"public.documents.id_location = l.id" search is underestimating the 
number of rows by a factor of 8.7.  You might get a better plan if you 
can get better table statistics on that column.  Did you run ANALYZE 
since the partitioning was done?  If not, that could be making this 
worse.  You might increase the amount of table statistics on this 
specific column too, not sure what would help without knowing exactly 
what's in there.

Another thing you can try is suggest the optimizer not use a hash join 
here and see if it does the right thing instead; be a useful bit of 
feedback to see what that plan turns out to be.  Just put "set 
enable_hashjoin=off;" before the rest of the query, it will only impact 
that session.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us