Re: Too few rows expected by Planner on partitioned tables

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Too few rows expected by Planner on partitioned tables
Дата
Msg-id 20200722122846.GS5748@telsasoft.com
обсуждение исходный текст
Ответ на Too few rows expected by Planner on partitioned tables  (Julian Wolf <julian.wolf@invenium.io>)
Список 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 по дате отправления:

Предыдущее
От: Julian Wolf
Дата:
Сообщение: Re: Too few rows expected by Planner on partitioned tables
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Too few rows expected by Planner on partitioned tables