Re: Problem with planner choosing nested loop

On Wed, Apr 2, 2008 at 1:20 PM, Alex Solovey <a(dot)solovey(at)gmail(dot)com> wrote:
> In this simple (which means "reduced") test database, yes. But the actual
> table "foo" in production database:
>
> 1. partitioned, with 50+ partitions
> 2. heavily updated (and indexes make it slow)
> 3. has more fields like bar_id
>
> We had indexes on several fields based on typical access patterns, but
> after "foo" grew to a certain size (many gigabytes), sequential scans on
> selected partitions became the only feasible solution.
> We can fix this particular query with an index, but the more general
> problem with planner choosing multiple scans over big table due to wrong
> estimate of results from the small table, remains.

Then provide actual DDL plus the production EXPLAIN ANALYZE output and
post it, maybe one of the Postgres gurus can help.

Good luck.