Re: Same query doing slow then quick - Mailing list pgsql-performance
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
Date: Wed, 26 Sep 2012 08:07:08 -0700
From: [hidden email]
To: [hidden email]
Subject: Re: Same query doing slow then quick
On 09/26/2012 16:41, FFW_Rude wrote:
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 ...
--
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 08:07:08 -0700
From: [hidden email]
To: [hidden email]
Subject: Re: Same query doing slow then quick
On 09/26/2012 16:41, FFW_Rude wrote:
Ok done to 512Mb and 2048MbI'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 TerritoryOu écouter ?Ou acheter ?La FnaciTunes
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-performanceIf 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
View this message in context: RE: Same query doing slow then quick
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
jcigar.vcf (304 bytes) -- 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-tp5725486p5725526.htmlView this message in context: RE: Same query doing slow then quick
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
pgsql-performance by date: