Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TGsyd-00075C-Si for pgsql-performance@postgresql.org; Wed, 26 Sep 2012 14:52:40 +0000 Received: from mxin.ulb.ac.be ([164.15.128.112]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TGsyY-0004dx-LM for pgsql-performance@postgresql.org; Wed, 26 Sep 2012 14:52:38 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoBAHwVY1CkD30E/2dsb2JhbAANOIJLg0CFX7YYAQEBAwEjKyAbCQIRAwECAQkEHQICAg0CIB4IDgUIAQEFFASHUgMJEaVobiuJChdCiQiLGBqEXYESA45ugSCGcIQ6jUWBWgc Received: from bebif01.ulb.ac.be (HELO [10.0.0.194]) ([164.15.125.4]) by smtp.ulb.ac.be with ESMTP; 26 Sep 2012 16:52:33 +0200 Message-ID: <506316B1.70900@ulb.ac.be> Date: Wed, 26 Sep 2012 16:52:33 +0200 From: Julien Cigar Organization: Belgian Biodiversity Platform User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:12.0) Gecko/20120503 Thunderbird/12.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Same query doing slow then quick References: <1348662446741-5725486.post@n5.nabble.com> <1348664629662-5725491.post@n5.nabble.com> <50630162.2090603@ulb.ac.be> <506307E2.4060504@ulb.ac.be> <1348668859243-5725505.post@n5.nabble.com> <50630E6F.5040605@ulb.ac.be> In-Reply-To: Content-Type: multipart/mixed; boundary="------------050202020306020409010003" X-Pg-Spam-Score: -3.9 (---) X-Archive-Number: 201209/134 X-Sequence-Number: 47880 This is a multi-part message in MIME format. --------------050202020306020409010003 Content-Type: multipart/alternative; boundary="------------030702080400000806020806" --------------030702080400000806020806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. --------------030702080400000806020806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 ?

Ou acheter ?
La Fnac

iTunes


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.
--------------030702080400000806020806-- --------------050202020306020409010003 Content-Type: text/x-vcard; charset=utf-8; name="jcigar.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="jcigar.vcf" YmVnaW46dmNhcmQNCmZuOkp1bGllbiBDaWdhcg0KbjpDaWdhcjtKdWxpZW4NCm9yZztxdW90 ZWQtcHJpbnRhYmxlOkJlbGdpYW4gQmlvZGl2ZXJzaXR5IFBsYXRmb3JtO1VMQiAoVW5pdmVy c2l0PUMzPUE5IExpYnJlIGRlIEJydXhlbGxlcykNCmFkcjo7OztCcnVzc2Vsczs7O0JlbGdp dW0NCmVtYWlsO2ludGVybmV0OmpjaWdhckB1bGIuYWMuYmUNCnRlbDt3b3JrOiszMigwKTI2 NTA1NzUyDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0KdXJsOmh0dHA6Ly93d3cuYmlvZGl2ZXJz aXR5LmJlDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------050202020306020409010003--