Re: Bad plan after vacuum analyze - Mailing list pgsql-performance

From Guillaume Smet
Subject Re: Bad plan after vacuum analyze
Date
Msg-id 4282723C.5080903@smet.org
Whole thread Raw
In response to Re: Bad plan after vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bad plan after vacuum analyze  (Markus Bertheau <twanger@bluetwanger.de>)
List pgsql-performance
Josh, Tom,

Thanks for your explanations.

> In the meantime it seems like the quickest answer for Guillaume might
> be to try to avoid keeping any NULLs in parent_application_id.

I can't do that as the majority of the applications don't have any
parent one. Moreover, we use a third party application and we cannot
modify all its internals.

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

So I think I will use this solution for the moment.

Thanks a lot for your help.

Regards

--
Guillaume

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bad plan after vacuum analyze
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Sort and index