On Mon, Mar 30, 2009 at 4:02 PM, <dan@xxxxxxxxx> wrote: >> On Mon, Mar 30, 2009 at 1:42 PM, <dan@xxxxxxxxx> wrote: >>>> On Mon, Mar 30, 2009 at 12:42 PM, <dan@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
