Re: Bad plan after vacuum analyze

From: Markus Bertheau <twanger(at)bluetwanger(dot)de>
To: Guillaume Smet <guillaume_ml(at)smet(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Bad plan after vacuum analyze
Date: 2005-05-13 18:35:35
Message-ID: 1116009335.7327.0.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

В Срд, 11/05/2005 в 22:59 +0200, Guillaume Smet пишет:

> Anyway, I tried to work on the statistics as you told me and here are
> the results:
> ccm_perf=# ALTER TABLE acs_objects ALTER COLUMN object_id SET STATISTICS 30;
> ALTER TABLE
> ccm_perf=# ANALYZE acs_objects;
> ANALYZE
>
> ccm_perf=# \i query_section.sql
> ... correct plan ...
> Total runtime: 0.555 ms

Given Tom's analysis, how can increasing the stats target change which
plan is chosen?

--
Markus Bertheau <twanger(at)bluetwanger(dot)de>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Joel Fradkin 2005-05-13 19:27:55 ok you all win what is best opteron (I dont want a hosed system again)
Previous Message John A Meinel 2005-05-13 18:32:42 Re: Optimize complex join to use where condition before