Re: 8.2.4 Chooses Bad Query Plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pallav Kalva <pkalva(at)livedatagroup(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: 8.2.4 Chooses Bad Query Plan
Date: 2007-08-28 21:06:12
Message-ID: 3926.1188335172@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Pallav Kalva <pkalva(at)livedatagroup(dot)com> writes:
> I have analyzed tables again and also my default_stats_target is set to
> 100, still it shows the same plan.

>>> -> Index Scan using idx_accountactivity_fkactivityid on
>>> accountactivity accountact0_ (cost=0.00..3.94 rows=1 width=16)
>>> Index Cond: (accountact0_.fkactivityid =
>>> activity1_.activityid)
>>> Filter: (fkaccountid = 1455437)

>>> -> Index Scan using
>>> idx_accountactivity_fkaccountid on accountactivity accountact0_
>>> (cost=0.00..1641.42 rows=1343 width=16) (actual time=115.348..864.416
>>> rows=10302 loops=1)
>>> Index Cond: (fkaccountid = 1455437)

Oh, my bad, I failed to look closely enough at these subplans.
I thought they were identical but they're not using the same scan
conditions, so the rowcount estimates shouldn't be comparable after all.

Could you try EXPLAINing (maybe even with ANALYZE) the query *without*
the LIMIT clause? I'm curious to see what it thinks the best plan is
then.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Decibel! 2007-08-28 21:34:04 Re: io storm on checkpoints, postgresql 8.2.4, linux
Previous Message Pallav Kalva 2007-08-28 19:28:59 Re: 8.2.4 Chooses Bad Query Plan