Re: Trying to track down weird query stalls
От | dan@sidhe.org |
---|---|
Тема | Re: Trying to track down weird query stalls |
Дата | |
Msg-id | 56164.199.172.169.17.1238443348.squirrel@localhost обсуждение исходный текст |
Ответ на | Re: Trying to track down weird query stalls (Scott Marlowe <scott.marlowe@gmail.com>) |
Ответы |
Re: Trying to track down weird query stalls
|
Список | pgsql-performance |
> On Mon, Mar 30, 2009 at 1:42 PM, <dan@sidhe.org> wrote: >>> On Mon, Mar 30, 2009 at 12:42 PM, <dan@sidhe.org> wrote: >>>> Arguably in this case the actual query should run faster than the >>>> EXPLAIN >>>> ANALYZE version, since the cache is hot. (Though that'd only likely >>>> shave >>>> a few dozen ms off the runtime) >>> >>> Joining a lot of tables together? Could be GEQO kicking in. >> >> Only if I get different query plans for the query depending on whether >> it's being EXPLAIN ANALYZEd or not. That seems unlikely... > > Yes, you can. In fact you often will. Not because it's being > explained or not, just because that's how GEQO works. Ouch. I did *not* know that was possible -- I assumed that the plan was deterministic and independent of explain analyze. The query has seven tables (one of them a temp table) and my geqo_threshold is set to 12. If I'm reading the docs right GEQO shouldn't kick in. -Dan
В списке pgsql-performance по дате отправления: