Re: Bad plan after vacuum analyze

From: Tom Lane
Subject: Re: Bad plan after vacuum analyze
Date: ,
Msg-id: 14301.1115840296@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Bad plan after vacuum analyze  (Guillaume Smet)
Responses: 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, )

Guillaume Smet <> writes:
>> If so, can we see the pg_stats rows for the object_id and
>> parent_application_id columns?

> See attached file.

Well, those stats certainly appear to justify the planner's belief that
the indexscan needn't run very far: the one value of
parent_application_id is 1031 and this is below the smallest value of
object_id seen by analyze.  You might have better luck if you increase
the statistics target for acs_objects.object_id.  (It'd be interesting
to know what fraction of acs_objects actually does have object_id < 1032.)

            regards, tom lane


pgsql-performance by date:

From: Enrico Weigelt
Date:
Subject: Re: BLOB's bypassing the OS Filesystem for better Image loading speed?
From: Bruce Momjian
Date:
Subject: Re: Intel SRCS16 SATA raid?