to tie the key size to
> NAMEDATALEN.
IMO, we should avoid magic numbers whenever possible. Current logic
according to which first users of this feature will be extensions
naturally bonds this size to the size of the 'name' type.
And one more point. I think the commit already deserves a mor
On 10/1/2024 20:27, Konstantin Knizhnik wrote:
On 10/01/2024 8:46 am, Michael Paquier wrote:
On Wed, Jan 10, 2024 at 01:29:30PM +0700, Andrei Lepikhov wrote:
What do you think about this really useful feature? Do you wish to
develop
it further?
I am biased here. This seems like a lot
combination,
building the dependency statistics is still massive work. So, in the
multicolumn case, having something like a histogram may be more effective.
--
regards,
Andrei Lepikhov
Postgres Professional
this code in my PR to send
actual amount of custom instrumentation data. But it can not help with
the cases above.
What do you think about this really useful feature? Do you wish to
develop it further?
--
regards,
Andrei Lepikhov
Postgres Professional
On 9/1/2024 16:45, vignesh C wrote:
On Tue, 9 Jan 2024 at 14:31, Andrei Lepikhov wrote:
Here is a new version of GROUP-BY optimization without sort model.
On 21/12/2023 17:53, Alexander Korotkov wrote:
I'd like to make some notes.
1) As already mentioned, there is clearly a repetitive
. Then in get_useful_group_keys_orderings() we should only deal
with input_path fully matching the group-by clause, and try only full
match of group-by output to the required order.
Hm, is it really make sense in current implementation?
--
regards,
Andrei Lepikhov
Postgres Professional
From ea068e221a754a463142575f6e0360d3118475f8
On 8/1/2024 01:36, Tomas Vondra wrote:
On 1/7/24 18:26, Andrei Lepikhov wrote:
On 7/1/2024 17:51, Tomas Vondra wrote:
On 1/7/24 11:22, Andrei Lepikhov wrote:
On 7/1/2024 06:54, Tomas Vondra wrote:
It's an interesting are for experiments, no doubt about it. And if you
choose to explore
On 7/1/2024 17:51, Tomas Vondra wrote:
On 1/7/24 11:22, Andrei Lepikhov wrote:
On 7/1/2024 06:54, Tomas Vondra wrote:
It's an interesting are for experiments, no doubt about it. And if you
choose to explore it, that's fine. But it's better to be aware it may
not end with a commit
a set of ANDed quals on different columns.
In your opinion, is it possible to add a hook into the extended
statistics to allow for an extension to propose alternative estimation?
[1] https://github.com/danolivo/pg_index_stats
--
regards,
Andrei Lepikhov
Postgres Professional
relid here.
Could you check your issue with the patch in the attachment? Does it
resolve this case?
--
regards,
Andrei Lepikhov
Postgres Professional
diff --git a/src/backend/optimizer/plan/analyzejoins.c
b/src/backend/optimizer/plan/analyzejoins.c
index 6c02fe8908..f79c673afd 100644
--- a/s
On 28/12/2023 18:29, Alexander Korotkov wrote:
On Thu, Dec 28, 2023 at 10:22 AM Andrei Lepikhov
wrote:
But arrangement with an ORDER BY clause doesn't work:
DROP INDEX abc;
explain SELECT x,w,z FROM t GROUP BY (w,x,z) ORDER BY (x,z,w);
I think the reason is that the sort_pathkeys
On 27/12/2023 12:07, Tom Lane wrote:
Andrei Lepikhov writes:
To be clear. In [1], I mentioned we can perform micro-benchmarks and
structure costs of operators. At least for fixed-length operators, it is
relatively easy.
I repeat what I said: this is a fool's errand. You will not get
of turning on choosing
between different sort column orderings if we have extended statistics
on the columns?
[1]
https://www.postgresql.org/message-id/e3602ccb-e643-2e79-ed2c-1175a8053...@postgrespro.ru
--
regards,
Andrei Lepikhov
Postgres Professional
On 21/12/2023 17:53, Alexander Korotkov wrote:
On Sun, Oct 1, 2023 at 11:45 AM Andrei Lepikhov
wrote:
New version of the patch. Fixed minor inconsistencies and rebased onto
current master.
Thank you (and other authors) for working on this subject. Indeed to
GROUP BY clauses are order
Hi,
Working on Asymmetric Join, I found slight inconsistency in the
description of SpecialJoinInfo: join type JOIN_ANTI can be accompanied
by a zero value of the ojrelid if this join was created by the
transformation of the NOT EXISTS subquery.
--
regards,
Andrei Lepikhov
Postgres
On 25/12/2023 18:36, Alexander Korotkov wrote:
On Fri, Dec 22, 2023 at 7:24 PM Andrei Lepikhov
wrote:
On 22/12/2023 11:48, Alexander Korotkov wrote:
> Because we must trust all predictions made by the planner, we just
> choose the most trustworthy path. According to the planner
COSTS_EQUAL.
--
regards,
Andrei Lepikhov
Postgres Professional
From 45bda9784d28dc9cec90c5b33285023a49850800 Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Mon, 27 Nov 2023 11:23:48 +0700
Subject: [PATCH] Choose an index path with the best selectivity estimation.
In the case w
gt; work into this.
Done
> 9. https://www.postgresql.org/message-id/154f786a-06a0-4fb1-
> b8a4-16c66149731b%40postgrespro.ru
--
regards,
Andrei Lepikhov
Postgres ProfessionalFrom 7b044de1449a5fdc450cb629caafb4e15ded7a93 Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date
to improve estimates even when there is no full match.
I have tried to use the knowledge about unique indexes in the
selectivity estimation routine. But it looks invasive and adds a lot of
overhead.
--
regards,
Andrei Lepikhov
Postgres Professional
On 20/12/2023 17:33, Nathan Bossart wrote:
On Wed, Dec 20, 2023 at 11:02:58AM +0200, Andrei Lepikhov wrote:
In that case, maybe change the test case to make it closer to real-life
usage - with locks and concurrent access (See attachment)?
I'm not following why we should make this test case
On 20/12/2023 07:04, Michael Paquier wrote:
On Tue, Dec 19, 2023 at 10:14:44AM -0600, Nathan Bossart wrote:
On Tue, Dec 19, 2023 at 10:49:23AM -0500, Robert Haas wrote:
On Mon, Dec 18, 2023 at 3:32 AM Andrei Lepikhov
wrote:
2. I think a separate file for this feature looks too expensive
On 18/12/2023 13:39, Andrei Lepikhov wrote:
On 5/12/2023 10:46, Nathan Bossart wrote:
I don't presently have any concrete plans to use this for anything, but I
thought it might be useful for extensions for caching, etc. and wanted to
see whether there was any interest in the feature.
I am
.
Designing extensions, every time I feel pain introducing one shared
value or some global stat, the extension must be required to be loadable
on startup only. It reduces the flexibility of even very lightweight
extensions, which look harmful to use in a cloud.
--
regards,
Andrei Lepikhov
Postgres
org/message-id/7a40707d-1758-85a2-7bb1-6e5775518e64%40postgrespro.ru
--
regards,
Andrei Lepikhov
Postgres Professional
up to the plan creation, we have some inconsistency
in expressions (partitions refer to expressions with the parent relid).
What if an extension in the middle changes the parent expression?
By and large, this patch is in a good state and may be committed.
--
regards,
Andrei Lepikhov
Postgres
On 11/12/2023 09:31, Richard Guo wrote:
On Fri, Dec 8, 2023 at 3:13 PM Alexander Pyhalov
mailto:a.pyha...@postgrespro.ru>> wrote:
Andrei Lepikhov писал(а) 2023-12-08 07:37:
> I'd already clashed with Tom on copying the required_relids field
and
> voluntarily made
we need right now: SJE is quite a rare
optimization and executes before the entries expansion procedure. So it
looks less risky.
[1] Asymmetric partition-wise JOIN
https://www.postgresql.org/message-id/flat/CAOP8fzaVL_2SCJayLL9kj5pCA46PJOXXjuei6-3aFUV45j4LJQ%40mail.gmail.com
--
regards,
And
)
--
regards,
Andrei Lepikhov
Postgres Professional
From 71746caae3eb0c771792b563fd53244fc1ac575b Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Thu, 23 Nov 2023 16:00:13 +0700
Subject: [PATCH] Transform OR clause to ANY expressions.
Replace (expr op C1) OR (expr op C2) ... with expr
d further.
--
regards,
Andrei Lepikhov
Postgres Professional
From 73031b7acae68494ddd0f9b1faf4c94aae3bd6b0 Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Thu, 23 Nov 2023 16:00:13 +0700
Subject: [PATCH] Transform OR clause to ANY expressions.
Replace (expr op C1) OR (expr op C2) .
On 30/11/2023 22:40, Konstantin Knizhnik wrote:
On 30/11/2023 5:59 am, Andrei Lepikhov wrote:
On 21/10/2023 19:16, Konstantin Knizhnik wrote:
EXPLAIN statement has a list of options (i.e. ANALYZE, BUFFERS,
COST,...) which help to provide useful details of query execution.
In Neon we have
. I'm only one vote here.
I agree; it should be disabled by default. The fact that memory
consumption outputs with byte precision (very uncomfortable for
perception) is a sign that the primary audience is developers and for
debugging purposes.
--
regards,
Andrei Lepikhov
Postgres Professional
e uniform ORs are grouped into
arrays, the optimizer will do such work with less overhead.
--
regards,
Andrei Lepikhov
Postgres Professional
.
--
regards,
Andrei Lepikhov
Postgres Professional
On 28/11/2023 04:03, Robert Haas wrote:
On Mon, Nov 27, 2023 at 3:02 AM Andrei Lepikhov
wrote:
On 25/11/2023 08:23, Alexander Korotkov wrote:
I think patch certainly gets better in this aspect. One thing I can't
understand is why do we use home-grown code for resolving
hash-collisions. You
,
Andrei Lepikhov
Postgres Professional
From 8a43f5b50be6cb431046ab352fbcb9bdd3e4376c Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Thu, 23 Nov 2023 16:00:13 +0700
Subject: [PATCH] Transform OR clause to ANY expressions.
Replace (X=N1) OR (X=N2) ... with X = ANY(N1, N2) on the p
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 +07
.
The 'errors table' must inherit any right policies from the table, to
which we do the copy.
--
regards,
Andrei Lepikhov
Postgres Professional
On 23/11/2023 16:23, Andrei Lepikhov wrote:
This code changes tests in many places. But, as I see it, it mostly
demonstrates the positive effect of the transformation.
I found out that the postgres_fdw tests were impacted by the feature.
Fix it, because the patch is on the commitfest
the positive effect of the transformation.
--
regards,
Andrei Lepikhov
Postgres Professional
From 5071d02426ac3430f4dd61a8ad32c2847ba6f8a5 Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Thu, 23 Nov 2023 16:00:13 +0700
Subject: [PATCH] Transform OR clause to ANY expressions.
Rep
out a unique index, but I don't have a better idea.
It looks a bit expensive for me. But I am ready to try, if current
solution doesn't look applicable.
--
regards,
Andrei Lepikhov
Postgres Professional
From 21677861e101eed22c829e0b14290a56786a12c2 Mon Sep 17 00:00:00 2001
From: "Andrey V. L
to generate expression hash instead + prove the equality of
two expressions by calling equal().
--
regards,
Andrei Lepikhov
Postgres Professional
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 25a4235dbd..de27d2646c 100644
--- a/src/backend/parser/parse_expr.c
--
regards,
Andrei Lepikhov
Postgres Professional
On 30/10/2023 14:55, Richard Guo wrote:
On Thu, Oct 26, 2023 at 12:07 PM Andrei Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
Do you've thought about the case, fixed with the commit 1db5667? As I
see, that bugfix still isn't covered by regression tests. Could your
ap
On 25/10/2023 20:00, Andrei Zubkov wrote:
Hi Andrei,
On Wed, 2023-10-25 at 13:59 +0700, Andrei Lepikhov wrote:
But minmax_stats_since and changes in the UI of the reset routine
look like syntactic sugar here.
I can't convince myself that it is really needed. Do you have some
set of cases
is {1}.
...
Any thoughts?
Do you've thought about the case, fixed with the commit 1db5667? As I
see, that bugfix still isn't covered by regression tests. Could your
approach of a PARAM_EXEC slot reusing break that case?
--
regards,
Andrei Lepikhov
Postgres Professional
proposed? Maybe we should
intensively work on adding the 'stats_since' parameter and continue the
discussion of the necessity of another one?
--
regards,
Andrei Lepikhov
Postgres Professional
On 20/10/2023 19:39, Stephen Frost wrote:
Greetings,
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
The only issue I worry about is the uncertainty and clutter that can be
created by this feature. In the worst case, when we have a complex error
stack (including the extension's CATCH
On 22/10/2023 05:01, Alexander Korotkov wrote:
On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov
wrote:
On 19/10/2023 01:50, Alexander Korotkov wrote:
This query took 3778.432 ms with self-join removal disabled, and
3756.009 ms with self-join removal enabled. So, no measurable
overhead
On 20/10/2023 05:06, Stephen Frost wrote:
Greetings,
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
On 19/10/2023 02:00, Stephen Frost wrote:
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
On 29/9/2023 09:52, Andrei Lepikhov wrote:
On 22/5/2023 22:59, reid.thomp
On 18/10/2023 16:59, Ashutosh Bapat wrote:
On Wed, Oct 18, 2023 at 10:55 AM Andrei Lepikhov
wrote:
But the clauses of A parameterized by P will produce different
translations for each of the partitions. I think we will need
different RelOptInfos (for A) to store these translations.
Does
On 19/10/2023 01:50, Alexander Korotkov wrote:
On Mon, Oct 16, 2023 at 11:28 AM Andrei Lepikhov
wrote:
On 12/10/2023 18:32, Alexander Korotkov wrote:
On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
wrote:
On 4/10/2023 14:34, Alexander Korotkov wrote:
> Relid replacement machin
On 19/10/2023 02:00, Stephen Frost wrote:
Greetings,
* Andrei Lepikhov (a.lepik...@postgrespro.ru) wrote:
On 29/9/2023 09:52, Andrei Lepikhov wrote:
On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote:
Attach patches updated to master.
Pulled from patch 2 back to patch 1 a change
On 18/10/2023 13:39, Richard Guo wrote:
On Fri, Oct 13, 2023 at 6:18 PM Andrei Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
On 23/8/2023 12:37, Richard Guo wrote:
> To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
> ForeignPath an
On 18/10/2023 12:15, Tom Lane wrote:
Andrei Lepikhov writes:
"SET foo.bar TO 'smth'" can immediately alter the placeholder's value.
But what is the reason that "ALTER SYSTEM SET foo.bar TO 'smth'" doesn't
do the same?
Because it's not supposed to take effect until you is
On 17/10/2023 17:09, Ashutosh Bapat wrote:
On Tue, Oct 17, 2023 at 2:05 PM Andrei Lepikhov
wrote:
On 16/10/2023 23:21, Ashutosh Bapat wrote:
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
Whenever I visited this idea, I hit one issue prominently - how would
we differentiate different scans
On 17/10/2023 07:19, Tom Lane wrote:
Currently we have this odd behavior (for a superuser):
regression=# ALTER SYSTEM SET foo.bar TO 'baz';
ERROR: unrecognized configuration parameter "foo.bar"
regression=# SET foo.bar TO 'baz';
SET
regression=# ALTER SYSTEM SET foo.bar TO 'baz';
ALTER SYSTEM
On 16/10/2023 23:21, Ashutosh Bapat wrote:
On Mon, Oct 16, 2023 at 10:24 AM Andrei Lepikhov
Whenever I visited this idea, I hit one issue prominently - how would
we differentiate different scans of the non-partitioned relation.
Normally we do that using different Relids but in this case we
On 12/10/2023 18:32, Alexander Korotkov wrote:
On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
wrote:
On 4/10/2023 14:34, Alexander Korotkov wrote:
> Relid replacement machinery is the most contradictory code here. We used
> a utilitarian approach and implemented a simplistic v
On 15/10/2023 17:25, Alexander Korotkov wrote:
On Sun, Oct 15, 2023 at 8:40 AM Andrei Lepikhov
wrote:
Thanks for such detailed feedback!
The rationale for this patch was to give the optimizer additional ways
to push down more joins into foreign servers. And, because of
asynchronous append
On 15/10/2023 07:18, Alexander Korotkov wrote:
Hi Alexander,
Hi Andrey,
Thank you for your work on this subject.
On Mon, Jan 17, 2022 at 1:42 PM Alexander Pyhalov
wrote:
The patch does not longer apply cleanly, so I rebased it. Attaching
rebased version.
Not surprising that the patch
On 23/8/2023 12:37, Richard Guo wrote:
To fix it we may need to modify RelOptInfos for Path, BitmapHeapPath,
ForeignPath and CustomPath, and modify IndexOptInfos for IndexPath. It
seems that that is not easily done without postponing reparameterization
of paths until createplan.c.
Attached is
On 13/10/2023 15:56, a.rybakina wrote:
Also I've incorporated improvements from Alena Rybakina except one for
skipping SJ removal when no SJ quals is found. It's not yet clear for
me if this check fix some cases. But at least optimization got skipped
in some useful cases (as you can see in
On 12/10/2023 18:32, Alexander Korotkov wrote:
On Thu, Oct 5, 2023 at 12:17 PM Andrei Lepikhov
We have almost the results we wanted to have. But in the last explain
you can see that nothing happened with the OR clause. We should use the
expression mutator instead of walker to handle
On 11/10/2023 02:29, Alena Rybakina wrote:
I have reviewed your patch and I noticed a few things.
Thanks for your efforts,
I have looked at the latest version of the code, I assume that the error
lies in the replace_varno_walker function, especially in the place where
we check the node by
On 4/10/2023 14:34, Alexander Korotkov wrote:
> Relid replacement machinery is the most contradictory code here. We used
> a utilitarian approach and implemented a simplistic variant.
> > 2) It would be nice to skip the insertion of IS NOT NULL checks when
> > they are not necessary. [1]
On 4/10/2023 14:34, Alexander Korotkov wrote:
Hi!
On Wed, Oct 4, 2023 at 9:56 AM Andrei Lepikhov
mailto:a.lepik...@postgrespro.ru>> wrote:
> On 4/10/2023 07:12, Alexander Korotkov wrote:
> > On Tue, Sep 12, 2023 at 4:58 PM Andrey Lepikhov
> > mailto:a.lepik...@p
On 4/10/2023 07:12, Alexander Korotkov wrote:
Hi!
Thanks for the review!
I think this is a neat optimization.
On Tue, Sep 12, 2023 at 4:58 PM Andrey Lepikhov
wrote:
On 5/7/2023 21:28, Andrey Lepikhov wrote:
During the significant code revision in v.41 I lost some replacement
operations.
On 29/9/2023 09:52, Andrei Lepikhov wrote:
On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote:
Attach patches updated to master.
Pulled from patch 2 back to patch 1 a change that was also pertinent
to patch 1.
+1 to the idea, have doubts on the implementation.
I have a question. I see
New version of the patch. Fixed minor inconsistencies and rebased onto
current master.
--
regards,
Andrey Lepikhov
Postgres Professional
From 2f5a42c8a53286f830e3376ff4d3f8b7d4215b4b Mon Sep 17 00:00:00 2001
From: "Andrey V. Lepikhov"
Date: Wed, 13 Sep 2023 11:20:03 +0700
Subject: [PATCH]
On 22/5/2023 22:59, reid.thomp...@crunchydata.com wrote:
Attach patches updated to master.
Pulled from patch 2 back to patch 1 a change that was also pertinent to patch 1.
+1 to the idea, have doubts on the implementation.
I have a question. I see the feature triggers ERROR on the exceeding of
101 - 170 of 170 matches
Mail list logo
