Re: Same query doing slow then quick

On 09/26/2012 15:36, FFW_Rude wrote:
> Hi,
>
> Thank you for your answer.
>
> It was already at 16MB and i upped it just this morning to 64MB. Still
> no change
>

that's normal, please configure shared_buffers and effective_cache_size
properly

> 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 06:22:35 -0700
> From: [hidden email] </user/SendEmail.jtp?type=node&node=5725495&i=0>
> To: [hidden email] </user/SendEmail.jtp?type=node&node=5725495&i=1>
> 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]
> <http:///user/SendEmail.jtp?type=node&node=5725493&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/5725493/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-tp5725486p5725493.html
>
> To 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-tp5725486p5725495.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.