The reduced database example has the same problem in EXPLAIN ANALYZE as
production one, here:
Seq Scan on bar (cost=0.00..393.07 rows=1 width=4) (actual
time=0.098..3.561 rows=24 loops=1)
That's why I posted the smallest dataset I could reproduce the problem with.
Rodrigo E. De León Pli
choosing multiple scans over big table due to wrong
estimate of results from the small table, remains.
Alex
Rodrigo E. De León Plicet wrote:
On Wed, Apr 2, 2008 at 12:36 PM, Alex Solovey <[EMAIL PROTECTED]> wrote:
... I have no idea how it could be fixed.
- CREATE INDEX xifoo ON foo(bar
Hello,
I was trying to optimize a slow query in database running 8.3.1. It
turned out that planner is choosing nested loop join resulting in
multiple sequential scans over the long table. Here is a simplified
database schema, consisting of two tables:
CREATE TABLE bar (
bar_id in
Tom,
> If you're feeling brave, try the patch I just committed to CVS.
I just did it. It works! According to the query plan, only one partition
is being examined now.
Is this patch going to be included in 8.3 only, or in 8.2 as well?
Thanks!
-
Sent via pgsql-general mailing list (pgsql-gene
Tom,
Thanks for the patch. We've tried it here, and it improved query plan
slightly (indeed, it looks exactly like the plan from 8.2.6 now).
But, as you've said, empty sub-joins are still not discarded, so query
execution time did not improve. And this is the same in both 8.2 and 8.3.
Note th
Martin,
> which if you dont want to scan ALL partitions must be set to 'on'
> constraint_exclusion = on
It is 'ON'. The problem is that it does not work well for 'UPDATE foo
... FROM bar' queries, when partitioned table 'foo' is joined with
another table.
Martin Gainty wrote:
Alex-
http://
Hello,
We have pretty big production database (running PostgreSQL 8.3.1) with
many partitioned tables. In most cases, they work well (since 8.2.1 at
least) -- constraint exclusion is able to select correct partitions.
However, there is an exception: queries on partitioned tables using
Postgre
