On Thu, Dec 21, 2023 at 10:41 AM Andrei Lepikhov
wrote:
>
> On 18/12/2023 15:29, Alexander Korotkov wrote:
> > Also, there is a set of patches [7], [8], and [9], which makes the
> > optimizer consider path selectivity as long as path costs during the
> > path selection. I've rechecked that none
On 18/12/2023 15:29, Alexander Korotkov wrote:
Also, there is a set of patches [7], [8], and [9], which makes the
optimizer consider path selectivity as long as path costs during the
path selection. I've rechecked that none of these patches could resolve
the original problem described in [1].
Hi!
I'd like to get this subject off the ground. The problem originally
described in [1] obviously comes from wrong selectivity estimation.
"Dependencies" extended statistics lead to significant selectivity miss
24/1000 instead of 1/1000. When the estimation is correct, the PostgreSQL
Second version of the patch - resolve non-symmetrical decision, thanks
to Teodor Sigaev's review.
--
regards,
Andrei Lepikhov
Postgres Professional
From 604899b6afe70eccbbdbf69ce254f37808c598db Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Mon, 27 Nov 2023 11:23:48 +0700
Subject:
Thanks for detaied answer,
On 3/11/2023 00:37, Tomas Vondra wrote:
On 9/25/23 06:30, Andrey Lepikhov wrote:
...
I can't stop thinking about this issue. It is bizarre when Postgres
chooses a non-unique index if a unique index gives us proof of minimum
scan.
That's true, but no one implemented
On 9/25/23 06:30, Andrey Lepikhov wrote:
> ...
> I can't stop thinking about this issue. It is bizarre when Postgres
> chooses a non-unique index if a unique index gives us proof of minimum
> scan.
That's true, but no one implemented this heuristics. So the "proof of
minimum scan" is merely
On 12/8/2021 06:26, Tomas Vondra wrote:
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended
Hi,
On 2022-07-11 12:57:36 +0500, Andrey Lepikhov wrote:
> On 7/8/22 03:07, Tom Lane wrote:
> > Andrey Lepikhov writes:
> > > On 12/8/21 04:26, Tomas Vondra wrote:
> > > > I wonder if we should teach clauselist_selectivity about UNIQUE indexes,
> > > > and improve the cardinality estimates
On 7/8/22 03:07, Tom Lane wrote:
Andrey Lepikhov writes:
On 12/8/21 04:26, Tomas Vondra wrote:
I wonder if we should teach clauselist_selectivity about UNIQUE indexes,
and improve the cardinality estimates directly, not just costing for
index scans.
I tried to implement this in different
Andrey Lepikhov writes:
> On 12/8/21 04:26, Tomas Vondra wrote:
>> I wonder if we should teach clauselist_selectivity about UNIQUE indexes,
>> and improve the cardinality estimates directly, not just costing for
>> index scans.
> I tried to implement this in different ways. But it causes
On 12/8/21 04:26, Tomas Vondra wrote:
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
I agree the current behavior is unfortunate, but I'm not convinced the
proposed patch is fixing the right place - doesn't this mean the index
costing won't match
On 8/12/21 4:26 AM, Tomas Vondra wrote:
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended
On 8/11/21 2:48 AM, Peter Geoghegan wrote:
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended statistics.
Any thoughts on this, Tomas?
On Wed, Jun 23, 2021 at 7:19 AM Andrey V. Lepikhov
wrote:
> Ivan Frolkov reported a problem with choosing a non-optimal index during
> a query optimization. This problem appeared after building of an
> extended statistics.
Any thoughts on this, Tomas?
--
Peter Geoghegan
Hi,
Ivan Frolkov reported a problem with choosing a non-optimal index during
a query optimization. This problem appeared after building of an
extended statistics.
I prepared the test case (see t.sql in attachment).
For reproduction of this case we need to have a composite primary key
index
15 matches
Mail list logo
