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
Date: Wed, 26 Sep 2012 06:22:35 -0700
From: [hidden email]
To: [hidden email]
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
Rude - Last Territory
Ou écouter ?
Ou acheter ?
La Fnac
iTunes
Date: Wed, 26 Sep 2012 06:22:35 -0700
From: [hidden email]
To: [hidden email]
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.
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
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
View this message in context: RE: Same query doing slow then quick
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
