Re: Trying to track down weird query stalls
От | Robert Haas |
---|---|
Тема | Re: Trying to track down weird query stalls |
Дата | |
Msg-id | 603c8f070903301313u1a9606a3m27da187b5e376785@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Trying to track down weird query stalls (dan@sidhe.org) |
Ответы |
Re: Trying to track down weird query stalls
|
Список | pgsql-performance |
On Mon, Mar 30, 2009 at 4:02 PM, <dan@sidhe.org> wrote: >> 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. Any chance we could see the actual query? Right now I think we are shooting in the dark. ...Robert
В списке pgsql-performance по дате отправления: