Search Postgresql Archives

Re: Problem with planner choosing nested loop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 2, 2008 at 1:20 PM, Alex Solovey <a.solovey@xxxxxxxxx> 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.

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux