Skip site navigation (1) Skip section navigation (2)

Re: Same query doing slow then quick

From: FFW_Rude <FFW_Rude(at)hotmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Same query doing slow then quick
Date: 2012-09-26 15:18:08
Message-ID: SNT111-W28A5F2A90FEADAB0F881F9E19C0@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-performance
It sure does not take less than a second :(
37minutes in and no results. I'm gonna wait until the end to see the result of the explain

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 Fnachttp://recherche.fnac.com/fmia14622213/Last-Territory
http://recherche.fnac.com/fmia14770622/Rude-Undertaker

iTuneshttp://itunes.apple.com/us/artist/last-territory/id533857009?ign-mpt=uo%3D4


Date: Wed, 26 Sep 2012 08:07:08 -0700
From: ml-node+s1045698n5725526h66(at)n5(dot)nabble(dot)com
To: FFW_Rude(at)hotmail(dot)com
Subject: Re: Same query doing slow then quick



	
  
    
  
  
    On 09/26/2012 16:41, FFW_Rude wrote:
    
      
        Ok done to 512Mb and 2048Mb
        

        
        I'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]

            To: [hidden
              email]

            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])
            

            To make changes to your subscription:
            

            http://www.postgresql.org/mailpref/pgsql-performance

            

               jcigar.vcf
              (304 bytes) Download
                Attachment
            

            

            
            
              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.html
            
            
              To unsubscribe from Same query doing slow then quick, click here.

              NAML 
          
        
      
      

      
      View this message in context: RE:
        Same query doing slow then quick

      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])

To make changes to your subscription:

http://www.postgresql.org/mailpref/pgsql-performance

 jcigar.vcf (422 bytes) Download Attachment

	
	
	
	

	

	
	
		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-tp5725486p5725526.html
	
	
		
		To unsubscribe from Same query doing slow then quick, click here.

		NAML
	 		 	   		  



--
View this message in context: http://postgresql.1045698.n5.nabble.com/Same-query-doing-slow-then-quick-tp5725486p5725527.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.

In response to

Responses

pgsql-performance by date

Next:From: Nikolay UlyanitskyDate: 2012-09-26 15:33:29
Subject: Re: Same query doing slow then quick
Previous:From: Julien CigarDate: 2012-09-26 14:52:33
Subject: Re: Same query doing slow then quick

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group