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+s1045698n5725493...@n5.nabble.com To: ffw_r...@hotmail.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.
