Re: too high planning time

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

 



Kenny Bachman <kenny.bachman17@xxxxxxxxx> writes:
> EXPLAIN ANALYZE select
>     i."DefinitionId",
> from
>     "T_WF_INSTANCE" i
> where
>     i."InstanceId" = 10045683193;

>        QUERY PLAN

> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Index Scan using
> "T_WF_INSTANCE_InstanceId_ApplicationCd_EntityStatusCd_idx" on
> "T_WF_INSTANCE" i  (cost=0.57..2.79 rows=1 width=34) (actual
> time=2.522..2.522 rows=1 loops=1)
>    Index Cond: ("InstanceId" = '10045683193'::bigint)

> * Planning Time: 8460.446 ms Execution Time: 2.616 ms*
> (4 rows)

It's hard to believe that such a simple query could take that
long to plan.  What I'm wondering is if the planner got blocked
on some other session's exclusive lock.  Not a lock on
"T_WF_INSTANCE" itself, because we'd have got that lock during
parsing before the "Planning Time" measurement starts.  But
there's going to be a physical access to the table's index
to determine its tree height, so an ex-lock on the index could
explain this.  Or an ex-lock on catalogs, particularly pg_statistic.
What else is going on in your database when this happens?

			regards, tom lane






[Index of Archives]     [Postgresql Home]     [Postgresql General]     [Postgresql Performance]     [Postgresql PHP]     [Postgresql Jobs]     [PHP Users]     [PHP Databases]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Forum]

  Powered by Linux