Re: Same query doing slow then quick

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.