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
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
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:
>>&
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.
>
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