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 13:36:45
Message-ID: SNT111-W18646B5C50D8B2D96AE68DE19C0@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-performance
Hi,
Thank you for your answer.
It was already at 16MB and i upped it just this morning to 64MB. Still no change

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 06:22:35 -0700
From: ml-node+s1045698n5725493h43(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 15:03, FFW_Rude wrote:

> Here is the answer to Ray Stell who send me the wiki page of Slow Query. I

> hope i detailed all you wanted (i basicly pasted the page and add my

> answers).

>

> Full Table and Index Schema:

>

> schema tables_adresses

> "Tables"

> tables_adresses.adresses_XX (id (serial), X(Double precision),Y (Double

> precision)).

> "Indexes"

> adresses_XX_pkey (Primary key, btree)

> calcul_XX (non unique, Btree on X,Y)

>

> schema tables_gps

> "Tables"

> tables_gps.gps_XX (id (int),x_max(numeric(10,5)), y_max

> (numeric(10,5)),x_min(numeric(10,5)),y_min(numeric(10,5)))

> "Indexes"

> calculs_XX (non unique Btree x_min,x_max,y_min,y_max)

> gps_10_pkey (Primary key on id btree)

>

> Approximate rows 250000.

> No large objects in it (just data)

> No NULL

> receives a large number of UPDATEs or DELETEs regularly

> is growing daily

>

> I can't post an EXPLAIN ANALYZE because of the 6hour query time.

>

> Postgres version: 9.1

>

> History: was this query always slow, : "YES"

>

> Hardware: Ubuntu server last version 32bits

>

> Daily VACUUM FULL ANALYZE, REINDEX TABLE on all the tables.

>

> WAL Configuration: Whats a WAL ?

>

> GUC Settings: i didn't change anything. All is standard.

>

> shared_buffers should be 10% to 25% of available RAM (it's on 24MB and can't

> go higher. The server has 4Gb)

>

> effective_cache_size should be 75% of available RAM =>  I don't now what this

> is.
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 start with shared_buffers to 512MB and 

effective_cache_size to 2GB


> Test changing work_mem: increase it to 8MB, 32MB, 256MB, 1GB. Does it make a

> difference? "No"


default work_mem is very small, set it to something like 16MB


>

>

>

> --

> View this message in context: http://postgresql.1045698.n5.nabble.com/Same-query-doing-slow-then-quick-tp5725486p5725491.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-tp5725486p5725493.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-tp5725486p5725495.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.

In response to

Responses

pgsql-performance by date

Next:From: Julien CigarDate: 2012-09-26 13:49:22
Subject: Re: Same query doing slow then quick
Previous:From: Julien CigarDate: 2012-09-26 13:21:38
Subject: Re: Same query doing slow then quick

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