On 2013-05-09 16:43, Larry Rosenman wrote:
> On 2013-05-09 16:40, Tom Lane wrote:
> Larry Rosenman <ler@lerctr.org> writes:
> On 2013-05-09 16:22, Tom Lane wrote:
> Perhaps it's blocked on a lock? Did you look into pg_locks?
> Did you note whether the process was consuming CPU time and/or doing
> IO?
>
> all the locks were clear, and it was consuming CPU and doing I/O
> (D->S->D state), etc.
>
> Hm. I'm suspicious that you still ended up with a seqscan checking
> plan. Was this session started after you added all the missing
> indexes?
> If not, it seems possible that it was using a bad pre-cached plan.
>
> regards, tom lane
> I added the indexes on last friday, and we've done a number of
> vacuumdb -zav's (every night) since then.
>
> So, if there's a cached plan, it's not from me.
>
> (we also restarted our app on Saturday night).
Any ideas on how to figure out if we ARE getting seqscan check plans,
and better
fix it?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
