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@xxxxxxxxxxxxxxx www.2ndQuadrant.us
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
