Re: Too few rows expected by Planner on partitioned tables - Mailing list pgsql-performance

From Justin Pryzby
Subject Re: Too few rows expected by Planner on partitioned tables
Date
Msg-id 20200722122846.GS5748@telsasoft.com
Whole thread Raw
In response to Too few rows expected by Planner on partitioned tables  (Julian Wolf <julian.wolf@invenium.io>)
List pgsql-performance
On Wed, Jul 22, 2020 at 06:33:17AM +0000, Julian Wolf wrote:
> Hello Justin,
> 
> 
> thank you very much for your fast response.
> 
> > Is there a correlation between daterange and spacial_feature_id ?
> 
> I am not entirely sure, what you mean by that. Basically, no, they are not correlated - spatial features are places
ona map, date ranges are time periods. But, as they are both part of a primary key in this particular table, they are
correlatedin some way as to be a part of uniquely identifying a row.
 
> 
> 
> > Are the estimates good if you query on *only* daterange?  spacial_feature_id ?
> Unfortunately no, they are not:

I checked and found that range types don't have "normal" statistics, and in
particular seem to use a poor ndistinct estimate..

                /* Estimate that non-null values are unique */
                stats->stadistinct = -1.0 * (1.0 - stats->stanullfrac);

You could try to cheat and hardcode a different ndistinct that's "less wrong"
by doing something like this:

ALTER TABLE t ALTER a SET (N_DISTINCT=-0.001);  ANALYZE t;

Maybe a better way is to create an index ON: lower(range),upper(range)
And then query: WHERE (lower(a),upper(a)) = (1,112);

Since you'd be storing the values separately in the index anyway, maybe this
means that range types won't work well for you for primary, searchable columns.

But if you're stuck with the schema, another kludge, if you want to do
something extra weird, is to remove statistics entirely by disabling
autoanalyze on the table and then manually run ANALYZE(columns) where columns
doesn't include the range column.  You'd have to remove the stats:

begin; DELETE FROM pg_statistic s USING pg_attribute a WHERE s.staattnum=a.attnum AND s.starelid=a.attrelid AND
starelid='t'::regclassAND a.attname='a';
 

-- 
Justin



pgsql-performance by date:

Previous
From: Julian Wolf
Date:
Subject: Re: Too few rows expected by Planner on partitioned tables
Next
From: Justin Pryzby
Date:
Subject: Re: Too few rows expected by Planner on partitioned tables