Re: [PERFORM] query planning different in plpgsql?

2009-10-29 Thread Michal J. Kubski
On Mon, 26 Oct 2009 14:09:49 -0400, Tom Lane wrote: > "Michal J. Kubski" writes: >> [ function that creates a bunch of temporary tables and immediately >> joins them ] > > It'd probably be a good idea to insert an ANALYZE on the temp tables > after you

Re: [PERFORM] query planning different in plpgsql?

2009-10-29 Thread Michal J. Kubski
On Mon, 26 Oct 2009 11:52:22 -0400, Merlin Moncure wrote: >>   Do you not have an index on last_snapshot.domain_id? >> > that, and also try rewriting a query as JOIN. There might be > difference in performance/plan. > Thanks, it runs better (average 240s, not 700s) with t

Re: [PERFORM] query planning different in plpgsql?

2009-10-26 Thread Michal J . Kubski
On Mon, 26 Oct 2009 09:19:26 -0400, Merlin Moncure wrote: > On Mon, Oct 26, 2009 at 6:05 AM, Michal J. Kubski > wrote: >> On Fri, 23 Oct 2009 16:56:36 +0100, Grzegorz Jaśkiewicz >> wrote: >>> On Fri, Oct 23, 2009 at 4:49 PM, Scott Mead >>> wrote: >>&

Re: [PERFORM] query planning different in plpgsql?

2009-10-26 Thread Michal J . Kubski
Hi, On Fri, 23 Oct 2009 16:56:36 +0100, Grzegorz Jaśkiewicz wrote: > On Fri, Oct 23, 2009 at 4:49 PM, Scott Mead > wrote: > >> >> >> Do you not have an index on last_snapshot.domain_id? >> > > that, and also try rewriting a query as JOIN. There might be difference in > performance/plan. >

[PERFORM] query planning different in plpgsql?

2009-10-23 Thread Michal J . Kubski
Hi, Is there any way to get the query plan of the query run in the stored procedure? I am running the following one and it takes 10 minutes in the procedure when it is pretty fast standalone. Any ideas would be welcome! # EXPLAIN ANALYZE SELECT m.domain_id, nsr_id FROM nsr_meta m, last_snapsho