On 09/26/2012 16:41, FFW_Rude wrote:
Ok done to 512Mb and 2048MbI'm relaunching. See you in a few hours (so tommorrow)
with 250 000 rows and proper indexes it should run in less than a second.be sure your indexes are set properly and that they're used (use EXPLAIN ANALYZE for that) within your query ...
Rude - Last Territory *Ou écouter ?*http://www.deezer.com/fr/music/last-territory/the-last-hope-3617781 (Post-apocalyptic Metal)http://www.deezer.com/fr/music/rude-undertaker (Pop-Rock) *Ou acheter ?* /La Fnac/ http://recherche.fnac.com/fmia14622213/Last-Territory http://recherche.fnac.com/fmia14770622/Rude-Undertaker /iTunes/http://itunes.apple.com/us/artist/last-territory/id533857009?ign-mpt=uo%3D4------------------------------------------------------------------------ Date: Wed, 26 Sep 2012 07:17:56 -0700 From: [hidden email] </user/SendEmail.jtp?type=node&node=5725518&i=0> To: [hidden email] </user/SendEmail.jtp?type=node&node=5725518&i=1> Subject: Re: Same query doing slow then quick On 09/26/2012 16:14, FFW_Rude wrote: > Thank for you answer. > > shared_buffer is at 24Mb > effective_cache_size at 2048Mb > > What do you mean properly ? That's not really helping a novice... > from my previous mail: before looking further, please configure shared_buffers and effective_cache_size properly, it's fundamental you'll probably need to raise SHMALL/SHMMAX, take a look at: http://www.postgresql.org/docs/current/static/kernel-resources.html for 4GB of RAM I would start with shared_buffers to 512MB and effective_cache_size to 2GB > > > --> View this message in context: http://postgresql.1045698.n5.nabble.com/Same-query-doing-slow-then-quick-tp5725486p5725505.html > Sent from the PostgreSQL - performance mailing list archive at Nabble.com.> > -- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --Sent via pgsql-performance mailing list ([hidden email] <http:///user/SendEmail.jtp?type=node&node=5725506&i=0>)To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance*jcigar.vcf* (304 bytes) Download Attachment <http://postgresql.1045698.n5.nabble.com/attachment/5725506/0/jcigar.vcf>------------------------------------------------------------------------If you reply to this email, your message will be added to the discussion below: http://postgresql.1045698.n5.nabble.com/Same-query-doing-slow-then-quick-tp5725486p5725506.htmlTo unsubscribe from Same query doing slow then quick, click here.NAML <http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble:email.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble:email.naml-instant_emails%21nabble:email.naml-send_instant_email%21nabble:email.naml>------------------------------------------------------------------------View this message in context: RE: Same query doing slow then quick <http://postgresql.1045698.n5.nabble.com/Same-query-doing-slow-then-quick-tp5725486p5725518.html> Sent from the PostgreSQL - performance mailing list archive <http://postgresql.1045698.n5.nabble.com/PostgreSQL-performance-f2050081.html> at Nabble.com.
-- No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced.
<<attachment: jcigar.vcf>>
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
