On Wed, Aug 26, 2020, 1:37 AM Julian Wolf wrote:
> Hi Justin,
>
> thank you very much for your help and sorry for the late answer.
>
> After testing around with your suggestions, it actually was the daterange
> type which caused all the problems. Messing around with the statistics
> value improve
Mailing List
Subject: Re: Too few rows expected by Planner on partitioned tables
On Tue, Jul 21, 2020 at 01:09:22PM +, Julian Wolf wrote:
> Hello,
>
> A description of what you are trying to achieve and what results you expect:
> Our database is growing on a daily basis by about 2.5mi
__
From: Justin Pryzby
Sent: Wednesday, July 22, 2020 4:40 PM
To: Julian Wolf
Cc: pgsql-performance Postgres Mailing List
Subject: Re: Too few rows expected by Planner on partitioned tables
On Tue, Jul 21, 2020 at 01:09:22PM +, Julian Wolf wrote:
> Hello,
>
>
performance Postgres Mailing List
Subject: Re: Too few rows expected by Planner on partitioned tables
On Tue, Jul 21, 2020 at 01:09:22PM +, Julian Wolf wrote:
> Our problem is, that the planner always predicts one row to be returned,
> although only a part of the primary key is queried. T
On Tue, Jul 21, 2020 at 01:09:22PM +, Julian Wolf wrote:
> Hello,
>
> A description of what you are trying to achieve and what results you expect:
> Our database is growing on a daily basis by about 2.5million rows per table
> (2 at the moment). Because of that, we decided to partition the da
On Wed, Jul 22, 2020 at 06:33:17AM +, 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 - s
On Tue, Jul 21, 2020 at 01:09:22PM +, Julian Wolf wrote:
> Our problem is, that the planner always predicts one row to be returned,
> although only a part of the primary key is queried. This problem exceeds
> feasibility of performance rapidly - a query only involving a few days
> already ta
Hello,
A description of what you are trying to achieve and what results you expect:
Our database is growing on a daily basis by about 2.5million rows per table (2
at the moment). Because of that, we decided to partition the data, especially,
as we are pre-aggregating the data for weeks, months,
