2009/9/18 :
>> Hi all,
>>
>> on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans
>> for one of our (weird) queries are generated. One of the query plans
>> seems to be good (and is used most of the time). The other one is bad -
>> the query takes about 2 minutes and the database
"Hell, Robert" writes:
> bad plan (sometimes with statistcs target 100, seconds after the good plan
> was chosen) - about 2 minutes: http://explain.depesz.com/s/gcr
> good plan (most of the time with statistcs target 100) - about one second:
> http://explain.depesz.com/s/HX
> very good plan (wit
On Thu, Sep 17, 2009 at 5:02 PM, André Volpato
wrote:
> André Volpato escreveu:
>>
>> (...)
>>
>> (Postgres 8.3.6, Debian Linux 2.6.18-6-amd64)
>>
>> (...)
>
>> Condition 1:
>> # select fat_referencia from bds_contratacao_fatura where fat_referencia
>> BETWEEN 200908 AND 200908;
>> Index Scan usin
On Fri, Sep 18, 2009 at 8:44 AM, Karl Wright wrote:
> Hi all,
>
> We're using Postgresql 8.3.7 on Debian. We are seeing a very strange
> performance situation with our application which I am hoping that someone
> can shed light on.
>
> Our tests find that our application runs quite well on 8.3.7
Hi all,
We're using Postgresql 8.3.7 on Debian. We are seeing a very strange performance situation with our application which I am
hoping that someone can shed light on.
Our tests find that our application runs quite well on 8.3.7 initially. The test consists of database creation followed by
Hi,
sorry about that.
We use 100 as default_statistics_target for this database. The default should
be 10 here - statistics are up to date I executed analyze manually this morning.
As mentioned before, the "bad plan" only happens once or twice a day - so the
reproduction of that plan is very d
> Hi all,
>
> on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans
> for one of our (weird) queries are generated. One of the query plans
> seems to be good (and is used most of the time). The other one is bad -
> the query takes about 2 minutes and the database process, which is
>
Hi all,
on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans
for one of our (weird) queries are generated. One of the query plans
seems to be good (and is used most of the time). The other one is bad -
the query takes about 2 minutes and the database process, which is
executing th
