Re: query planning different in plpgsql? - Mailing list pgsql-performance

From Michal J. Kubski
Subject Re: query planning different in plpgsql?
Date
Msg-id 3d1f13b434eef584e404153f43511c65@localhost
Whole thread Raw
In response to Re: query planning different in plpgsql?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Mon, 26 Oct 2009 14:09:49 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Michal J. Kubski" <michal.kubski@cdt.pl> 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 fill them.  The way you've got this set up, there is no chance
> of auto-analyze correcting that oversight for you, so the planner will
> be planning the join "blind" without any stats.  Good results would only
> come by pure luck.
> 
>             regards, tom lane

Hi,

Apologies for late response. Thanks a lot: ANALYZE seem to help it! I
still sometimes
get long query runs though. As far as I understand using index over
sequential scan
on joins should be faster. Could it be possible that the query planner
decides
to use seqscan instead of index scan on some random occasions? 

Thanks,
Michal

-- 
I hear and I forget. I see and I believe. I do and I understand.
(Confucius)

pgsql-performance by date:

Previous
From: Denis BUCHER
Date:
Subject: Re: Postgresql optimisation
Next
From: Peter Meszaros
Date:
Subject: database size growing continously