On 25/9/2025 12:41, Frédéric Yhuel wrote:
So, on SQL Server, you can do this:
CREATE STATISTICS FooStats ON foo (ackid, crit) WHERE crit = 'WARNING';
It would be great to have a similar feature in PostgreSQL.Nice! Thanks for the report. I think the only reason why Postgres
doesn't have it yet i
On 10/10/2025 10:51, Frits Jalvingh wrote:
Hi Andrei,
Thanks a lot for your response. I do not fully get it though because the
well-performing query also references the outer (external?) relation:
-> where eenheid.id_h_eenheid = eenheid_s.id_h_eenheid
But your response made me think a but more.
On 22/9/2025 18:09, Frédéric Yhuel wrote:
On 9/22/25 15:57, Andrei Lepikhov wrote:
I wonder if we could devise another kind of extended statistic that
would provide these "partitioned statistics" without actually partitioning.I'm not sure I fully understand your case, but SQL Server demonstrates
On Tue, 30 Sept 2025 at 02:49, Lauro Ojeda wrote:
> By looking into it, I have the impression there is a bug in the costing sum
> in that situation, where the cost of the "never executed" partitions should
> be deducted from the final cost estimation, which would make pruning to be
> the prefer
Andrei Lepikhov writes:
> On 25/9/2025 12:41, Frédéric Yhuel wrote:
>> So, on SQL Server, you can do this:
>> CREATE STATISTICS FooStats ON foo (ackid, crit) WHERE crit = 'WARNING';
> Nice! Thanks for the report. I think the only reason why Postgres
> doesn't have it yet is the computational cos
Hi David,
Thank you for your nice reply.
I have the impression there is something heavily penalizing the usage of
partition pruning. While trying to go a bit further, I realized that
partition pruning is not occurring because the planner gives the cost of
seq-scanning all partitions to just over 2
