Re: Bad plan after vacuum analyze

From: Markus Bertheau
Subject: Re: Bad plan after vacuum analyze
Date: ,
Msg-id: 1116009335.7327.0.camel@localhost.localdomain
(view: Whole thread, Raw)
In response to: Re: Bad plan after vacuum analyze  (Guillaume Smet)
List: pgsql-performance

Tree view

Bad plan after vacuum analyze  (Guillaume Smet, )
 Re: Bad plan after vacuum analyze  (Josh Berkus, )
  Re: Bad plan after vacuum analyze  (Tom Lane, )
   Re: Bad plan after vacuum analyze  (Guillaume Smet, )
    Re: Bad plan after vacuum analyze  (Tom Lane, )
     Re: Bad plan after vacuum analyze  (Guillaume Smet, )
      Re: Bad plan after vacuum analyze  (Tom Lane, )
       Re: Bad plan after vacuum analyze  (Guillaume Smet, )
        Re: Bad plan after vacuum analyze  (Markus Bertheau, )
 Re: Bad plan after vacuum analyze  (Mischa Sandberg, )

В Срд, 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 <>

Attachment

pgsql-performance by date:

From: Josh Berkus
Date:
Subject: Re: Postgresql Performance via the LSI MegaRAID 2x Card
From: PFC
Date:
Subject: Re: Partitioning / Clustering