From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_stat_advisor extension |
Date: | 2024-02-08 07:14:18 |
Message-ID: | 378f525e-fd0d-48d5-8dc9-bcdd9fffd84f@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/2/2024 22:27, Ilia Evdokimov wrote:
>
> I welcome your insights, feedback, and evaluations regarding the
> necessity of integrating this new extension into PostgreSQL.
Besides other issues that were immediately raised during the discovery
of the extension, Let me emphasize two issues:
1. In the case of parallel workers the plan_rows value has a different
semantics than the number of rows predicted. Just explore
get_parallel_divisor().
2. The extension recommends new statistics immediately upon an error
finding. But what if the reason for the error is stale statistics? Or
this error may be raised for only one specific set of constants, and
estimation will be done well in another 99.9999% of cases for the same
expression.
According to No.2, it might make sense to collect and track clause
combinations and cardinality errors found and let the DBA make decisions
on their own.
--
regards,
Andrei Lepikhov
Postgres Professional
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2024-02-08 07:20:12 | Re: table inheritance versus column compression and storage settings |
Previous Message | Peter Eisentraut | 2024-02-08 07:06:28 | Re: Testing autovacuum wraparound (including failsafe) |