Index Cond: (id = 2)
thanks
Marcos
--
Regards,
Alena Rybakina
From 56fba3befe4f6b041d097d8884815fe943fb21f9 Mon Sep 17 00:00:00 2001
From: Alena Rybakina
Date: Mon, 26 Jun 2023 04:18:15 +0300
Subject: [PATCH] Replace clause (X=N1) OR (X=N2) ... with X = ANY(N1, N2) on
the stage of t
attach a file
with diff.
On 26.06.2023 04:47, Alena Rybakina wrote:
Hi, all! Sorry I haven't written for a long time.
I finished writing the code patch for transformation "Or" expressions
to "Any" expressions. I didn't see any problems in regression tests,
even when
case of calculating underestimated cardinality for
an LEFT JOIN with the restriction "IS NULL" in the clause. This error is
caused by an incorrect calculation of selectivity in the "IS NULL" clause,
since it took into account only table-level statistics without zero values
Buckets: 131072 Batches: 1 Memory Usage: 6474kB
-> Seq Scan on b (cost=0.00..1637.00 rows=10 width=20)
(actual time=0.015..11.819 rows=10 loops=1)
Planning Time: 0.194 ms
Execution Time: 104.662 ms
(8 rows)
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/sr
opname = "AND";
break;
case OR_EXPR:
opname = "OR";
or_statement = true;
break;
case NOT_EXPR:
opname = "NOT";
break;
default:
elog(ERROR, "unrecognized boolop: %d", (int) expr->boolop);
opname = N
Hi! I'm sorry I didn't answer you right away, I was too busy with work.
On 27.06.2023 22:50, Peter Geoghegan wrote:
On Tue, Jun 27, 2023 at 6:19 AM Alena Rybakina wrote:
I learned something new from your letter, thank you very much for that!
Cool. The MDAM paper is also worth a re
bed the problem more or less clearly here [1] and the worst
case, as it seems to me, too, but if this is not the case, let me know.
1.
https://www.mail-archive.com/pgsql-hackers@lists.postgresql.org/msg146230.html
On 29.06.2023 12:32, Alena Rybakina wrote:
Hi! I'm sorry I didn't an
rly
optimizations.
Thank you again for your interest in this problem and help. Yes, I think
so too)
1. https://github.com/gregrahn/join-order-benchmark
2.
https://github.com/Alena0704/s64da-benchmark-toolkit/tree/master/benchmarks/tpcds
--
Regards,
Alena Rybakina
Postgres Professional
From f
On 29.06.2023 14:23, Ranier Vilela wrote:
Em qui., 29 de jun. de 2023 às 06:56, Alena Rybakina
escreveu:
I apologize for breaks the original thread. In my defense, I can
say that I'm new to all this and I'm just learning. I will try to
make as few mistakes as possib
thout matches has NULLs in all columns. In a way, we know
exactly how are these columns correlated - if we do the usual estimation
(even with the null_frac adjusted), we just throw this information away.
And when there's a lot of rows without a match, that seems bad.
--
Regards,
Alena Rybakin
Hi! Thank you for your detailed review, your changes have greatly helped
to improve this patch.
On 06.07.2023 13:20, Andrey Lepikhov wrote:
On 6/7/2023 03:06, Alena Rybakina wrote:
I corrected this constant in the patch.
The patch don't apply cleanly: it contains some trailing space
o start with this and implement the
patch.
I hope this makes more sense. If not, let me know and I'll try to
explain it better.
Thank you for your explanation)
I will unsubscribe soon based on the results or if I have any questions.
--
Regards,
Alena Rybakina
Postgres Professional
Hi! Thank you very much for your review! Sorry for my late response I
was overwhelmed by tasks.
On 16.08.2024 14:12, jian he wrote:
On Thu, Aug 15, 2024 at 4:49 PM Alena Rybakina
wrote:
Hi!
I've applied all the v5 patches.
0002 and 0003 have white space errors.
+
+Numb
s relkind,
you may need to use get_rel_relkind.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
SELECT count(*) FROM pg_stat_all_tables ;
count
---
108
(1 row)
SELECT count(*) FROM pg_stat_vacuum_tables ;
count
---
20
(1 row)
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ch. So, there is no regression. I would leave this
as is to not make this feature too complicated. This could be improved
in future though.
--
Regards,
Alexander Korotkov
Supabase
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 23.08.2024 19:38, Alexander Korotkov wrote:
Hi, Alena!
On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
wrote:
To be fair, I fixed this before [0] by selecting the appropriate group
of "or" expressions to transform them to "ANY" expression and then
checking for compatib
:
On Sat, Aug 24, 2024 at 4:08 PM Alena Rybakina
wrote:
On 23.08.2024 19:38, Alexander Korotkov wrote:
Hi, Alena!
On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
wrote:
To be fair, I fixed this before [0] by selecting the appropriate group
of "or" expressions to transform them to "
On 22.08.2024 05:47, jian he wrote:
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_
On 22.08.2024 07:29, Kirill Reshke wrote:
On Thu, 22 Aug 2024 at 07:48, jian he wrote:
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
about something else?
On 19.08.2024 12:32, jian
27;s unfair. I think that conversion to a single
type should be used here - while I’m working on this, I’ll send the code
in the next letter.
And I noticed that there were some tests missing on this, so I added this.
I've updated the patch file to include my and Jian's suggestions, as
w
Just in case, I have attached a diff file to show the changes for the
latest version attached here [0] to make the review process easier.
[0]
https://www.postgresql.org/message-id/c4e4e305-7119-4183-b49a-d7092f4efba3%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional: http
Hi!
On 03.09.2024 12:52, Andrei Lepikhov wrote:
If OR constants have different types, then they belong to different
groups, and I think that's unfair. I think that conversion to a
single type should be used here - while I’m working on this, I’ll
send the code in the next letter.
IMO, that mean
On 04.09.2024 18:31, Alena Rybakina wrote:
I rewrote the tests with integer types. Thanks for your suggestion. If
you don't mind, I've updated the diff file you attached earlier to
include the tests.
Sorry, I've just noticed that one of your changes with the regression
test was
While working on the "POC, WIP: OR-clause support for indexes" project
[0], it was suggested to use the construct_array function to form a
one-dimensional array.
I noticed that there is a comment that values with NULL are not
processed there, but in fact this function calls the construct_md_
On 12.09.2024 20:44, Tom Lane wrote:
Alena Rybakina writes:
I noticed that there is a comment that values with NULL are not
processed there, but in fact this function calls the construct_md_array
function, which
contains a comment that it can handle NULL values.
Right. construct_md_array
Hi!
On 09.09.2024 13:36, Alexander Korotkov wrote:
On Wed, Sep 4, 2024 at 6:42 PM Alena Rybakina wrote:
On 04.09.2024 18:31, Alena Rybakina wrote:
I rewrote the tests with integer types. Thanks for your suggestion. If
you don't mind, I've updated the diff file you attached earlier
Hi! Thanks for your contribution to this topic!
On 17.07.2024 03:03, Alexander Korotkov wrote:
Hi, Alena!
On Thu, Jul 11, 2024 at 7:17 PM Alena Rybakina
wrote:
I have finished patch and processed almost your suggestions (from [0], [1],
[2]). It remains only to add tests where the conversion
On 18.07.2024 23:01, Tom Lane wrote:
Alena Rybakina writes:
I fixed it. The code remains the same.
I see the cfbot is again complaining that this patch doesn't apply.
In hopes of pushing this over the finish line, I fixed up the (minor)
patch conflict and also addressed the cos
s best I can, but it took me a while to figure out
how to properly organize RestrictInfo in the index.
[0]
https://www.postgresql.org/message-id/3b9bb831-da52-4779-8f3e-f8b6b83ba41f%40postgrespro.ru
[1]
https://www.postgresql.org/message-id/CAPpHfdvhWE5pArZhgJeLViLx3-A3rxEREZvfkTj3E%3Dh7q-Bx9w%40mail.gmail.com
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 22.07.2024 03:52, Alexander Korotkov wrote:
Hi, Alena!
Let me answer to some of your findings.
On Mon, Jul 22, 2024 at 12:53 AM Alena Rybakina
wrote:
To be honest,I saw a larger problem. Look at the query bellow:
master:
alena@postgres=# create table t (a int not null, b int not null
On 27.07.2024 13:56, Alexander Korotkov wrote:
On Thu, Jul 25, 2024 at 5:04 PM Alena Rybakina
wrote:
To be honest, I have found a big problem in this patch - we try to perform the
transformation every time we examime a column:
for (indexcol = 0; indexcol < index->nkeycolumns; in
Ok, thank you for your work)
I think we can leave only the two added libraries in the first patch,
others are superfluous.
On 05.08.2024 22:48, Alexander Korotkov wrote:
On Mon, Jul 29, 2024 at 5:36 AM Alexander Korotkov wrote:
On Sun, Jul 28, 2024 at 12:59 PM Alena Rybakina
Because of
On 07.08.2024 04:11, Alexander Korotkov wrote:
On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
wrote:
Ok, thank you for your work)
I think we can leave only the two added libraries in the first patch,
others are superfluous.
Thank you.
I also have fixed some grammar issues.
Thank you)
I
nd_plan() inserts sort node.
In this case mark_async_capable() can treat Sort plan node as some
other and crash, so there's a small fix for this.
I think you should add this explanation to the commit message because
without it it's hard to understand the full picture of how your cod
Hi! I think your work is important)
I started reviewing it and want to suggest some changes to better code:
I think we should consider the case where the expression is not neither
an OpExpr and VarOpVar expression.
Have you tested this code with any benchmarks?
--
Regards,
Alena Rybakina
Hi!
On 07.08.2024 04:11, Alexander Korotkov wrote:
On Mon, Aug 5, 2024 at 11:24 PM Alena Rybakina
wrote:
Ok, thank you for your work)
I think we can leave only the two added libraries in the first patch,
others are superfluous.
Thank you.
I also have fixed some grammar issues.
While
g/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW
-- see "Note" box
--
Peter Geoghegan
To be honest, I don't quite understand how information in explain
analyze about the number of used primitive indexes
will help me improve my database system as a user. Pe
On 08.10.2024 18:49, Laurenz Albe wrote:
On Tue, 2024-10-08 at 18:12 +0300, Alena Rybakina wrote:
However you are right that this display will not appear for all
nodes that only contain a data collection procedure, such as Append,
MergeAppend, Gather, etc. And I agree with you that we should
Sorry, I was in a hurry and didn't check my patch properly.
On 14.10.2024 23:20, Alena Rybakina wrote:
On 28.08.2024 15:58, Benoit Lobréau wrote:
Hi,
Here is a new version of the patch. Sorry for the long delay, I was
hit by a motivation drought and was quite busy otherwise.
The guc i
the cost of Append is the sum of the subpath costs, but we
don't take pathkeys into account for subpaths, right?
--
Regards,
Alena Rybakina
Postgres Professional
From 9e9c5ff8aa977ec339c20433a427d98e15f8ed9d Mon Sep 17 00:00:00 2001
From: Alena Rybakina
Date: Tue, 15 Oct 2024 01:05:38
ssary parameters for that. To be
honest if the parameters weren't stored in a different struct for
parallel queries, I would have put it in a macro.
I attached the diff file including my proposals.
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/doc/src/sgml/config.sgml
On 07.10.2024 19:02, Laurenz Albe wrote:
On Mon, 2024-10-07 at 10:17 +0300, Alena Rybakina wrote:
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index ff689b65245..db906841472 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -578,6 +578,28 @@ WHERE
y with it and will likely push it on New
Zealand Friday (aka later today).
David
I think you missed some previous output and we should fix that.
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/test/regress/expected/collate.icu.utf8.out b/src/test/regress/expected/collate.icu
On 03.10.2024 23:10, Laurenz Albe wrote:
On Thu, 2024-10-03 at 14:24 -0400, Robert Haas wrote:
On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina wrote:
I prepared a patch that includes the information we can add.
One general thing to think about is that we really document very
little about
c333132"}'::bytea[]))
(4 rows)
Yes I meant it.
Do you plan to send your implementation to the hackers?
It was sent here [0].
[0]
https://www.postgresql.org/message-id/21d5fca5-0c02-4afd-8c98-d0930b298a8d%40gmail.com
--
Regards,
Alena Rybakina
Postgres Professional
as not to increase or decrease the
number of parallel workers when it is not necessary?
--
Regards,
Alena Rybakina
Postgres Professional
t's clearer what's going on and what it means.
--
Regards,
Alena Rybakina
Postgres Professional
Hi!
On 16.10.2024 13:31, Ilia Evdokimov wrote:
On 08.10.2024 19:18, Alena Rybakina wrote:
Made a rebase on a fresh master branch.
--
Regards,
Alena Rybakina
Postgres Professional
Thank you for rebasing.
I have noticed that when I create a table or an index on this table,
there is no
On 07.10.2024 03:41, Michael Paquier wrote:
On Mon, Oct 07, 2024 at 12:43:18AM +0300, Alena Rybakina wrote:
Maybe I'm not aware of the whole context of the thread and maybe my
questions will seem a bit stupid, but honestly
it's not entirely clear to me how this statistics will help
level,
and only then did an analysis of each table and index.
[0] https://commitfest.postgresql.org/50/5012/
--
Regards,
Alena Rybakina
Postgres Professional
On 02.10.2024 22:08, Laurenz Albe wrote:
On Wed, 2024-10-02 at 21:31 +0300, Alena Rybakina wrote:
Honestly, I like this patch. Before this patch, when disabling any algorithm
in the optimizer, the cost increased significantly and I’m not sure that this
was a reliable solution due to the fact
s better resolved
in the next thread related to the patch.
[0]
https://www.postgresql.org/message-id/CAPpHfdvF864n%3DLzmjd2XBi9TwboZvrhRtLSt2hCP%2BJVUv6XKzg%40mail.gmail.com
[1]
https://www.postgresql.org/message-id/985f2924-9769-4927-ad6e-d430c394054d%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
fact that
the partitioned table can also be scanned by an index. Besides
mergeappend, in general it’s difficult for me to generalize for which
nodes this rule applies, can you explain here?
--
Regards,
Alena Rybakina
Postgres Professional
://danolivo.substack.com/p/7456653e-9716-4e91-ad09-83737784c665
--
Regards,
Alena Rybakina
Postgres Professional
that the scan
is complete, so if this section of code is called, something is wrong
earlier in the code.
--
Regards,
Alena Rybakina
Postgres Professional
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?
Otherwise, we need this when we display information on al
dentity, ATExecSetIdentity and ATExecAddIdentity functions.
So, I'm willing to agree with you.
BTW, the regression tests were successful.
--
Regards,
Alena Rybakina
Postgres Professional
Hi!
On 29.10.2024 14:02, Alena Rybakina wrote:
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?
Otherwis
Assert (node != NULL);
+
examine_variable(root, node, 0, &vardata);
if (!HeapTupleIsValid(vardata.statsTuple))
continue;
--
Regards,
Alena Rybakina
Postgres Professional
ut contains only immutable functions, so we have to check * that.)
I also figured out more information about loosy variable. First of all,
I tried changing the value of the variable and did not notice any
difference in regression tests. As I understood, our transformation is
completely equivalen
m full operation doesn't call a vacuum operation, so we can't
collect statistics for it. Furthermore, this is a different operation
than vacuum because it completely rebuilds the table and indexes, so it
looks like your previous table and its indexes were completely removed.
To sum up, I t
anning Time: 1.464 ms
Execution Time: 0.352 ms
(11 rows)
--
Regards,
Alena Rybakina
Postgres Professional
On 29.10.2024 05:47, Andrei Lepikhov wrote:
On 10/28/24 16:48, Alena Rybakina wrote:
On 23.10.2024 04:39, Andrei Lepikhov wrote:
On 15/10/2024 12:15, David Rowley wrote:
And the last patch is a demo of how I'm going to use the previous
three patches and add one more strategy to improv
On 09.11.2024 21:46, Peter Geoghegan wrote:
On Sat, Nov 9, 2024 at 12:37 PM Alena Rybakina
wrote:
I noticed that the "Index Searches" cases shown in the regression tests are
only for partitioned tables, maybe something you should add some tests for regular tables
like tenk1.
I a
ss it. In addition, the user may not enable the
parameter for the object in time, because he will forget about it.
As for the second option, now I cannot say which statistics can be
removed, to be honest. So far, they all seem necessary.
--
Regards,
Alena Rybakina
Postgres Professional
function decides which path is better based on fewer disabled nodes.
hashjoin and nestedloop have 1 more nodes compared to mergejoin. you can
disable mergejoin, I think the output about this will appear.
--
Regards,
Alena Rybakina
Postgres Professional
cost
even without disabling can be greatly increased because of the high
cardinality, for example.
Right there, the mechanism is simple and more honest in my opinion - we
simply count the number of disabled nodes and discard the paths with the
largest number of them.
--
Regards,
Alena
Hash Join
Hash Cond: (tab_a.id = tab_b.id)
-> Seq Scan on tab_a
-> Hash
-> Seq Scan on tab_b
--
Regards,
Alena Rybakina
Postgres Professional
On 03.10.2024 01:44, David Rowley wrote:
On Thu, 3 Oct 2024 at 08:41, Alena Rybakina wrote:
I may have misunderstood your message, but disabled nodes number must propagate
up the tree, otherwise it will be incorrect.
I think there are two misunderstandings on this thread:
1) You&#x
ormation to doc/src/sgml/perform.sgml.
It contains a description about "explain queries", so the description of
"Disabled nodes" is available there.
I prepared a patch that includes the information we can add.
--
Regards,
Alena Rybakina
Postgres Professional
From 3670f1432
wrong yet. I think it's worth adding a test
to regression tests, isn't it?
--
Regards,
Alena Rybakina
Postgres Professional
ws=50 width=12)
Filter: (x = y)
(4 rows)
but the order of the columns does not change, as you can see.
--
Regards,
Alena Rybakina
Postgres Professional
On 29.11.2024 03:04, Alexander Korotkov wrote:
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
wrote:
On 28.11.2024 22:28, Ranier Vilela wrote:
Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
escreveu:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
Hello
On 28.11.2024 22:28, Ranier Vilela wrote:
Em qui., 28 de nov. de 2024 às 16:03, Alena Rybakina
escreveu:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
> Hello Alexander,
>
> 21.11.2024 09:34, Alexander Korotkov wrote:
>> I&
nodeIndexscan.c:1625
I found out what the problem is index scan method was not generated. We
need to check this during OR clauses for SAOP transformation.
There is a patch to fix this problem.
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/backend/optimizer/path/indxpath.
Sorry, I was in a hurry and forgot to add the test result. I updated the
patch
On 28.11.2024 22:03, Alena Rybakina wrote:
Hi! Thank you for the case.
On 28.11.2024 21:00, Alexander Lakhin wrote:
Hello Alexander,
21.11.2024 09:34, Alexander Korotkov wrote:
I'm going to push this
: 1 Memory Usage: 169kB -> Seq Scan on t2 (cost=0.00..14.10
rows=910 width=8) (actual time=0.018..0.239 rows=910 loops=1) Planning
Time: 0.215 ms Execution Time: 2.926 ms (11 rows)
Cardinality is predicted correctly as I see. I'm missing something?
--
Regards,
Alena Rybakina
Postgres Professional
Hi!
On 27.11.2024 16:36, Matthias van de Meent wrote:
On Wed, 27 Nov 2024 at 14:22, Alena Rybakina wrote:
Sorry it took me so long to answer, I had some minor health complications
On 12.11.2024 23:00, Peter Geoghegan wrote:
On Sun, Nov 10, 2024 at 2:00 PM Alena Rybakina
wrote:
Or maybe I
Index Searches" cases shown in the regression tests
are only for partitioned tables, maybe something you should add some
tests for regular tables like tenk1.
In general, I support the initiative to display this information in the
query plan output. I think it is necessary for finding the rea
Sorry it took me so long to answer, I had some minor health complications
On 12.11.2024 23:00, Peter Geoghegan wrote:
On Sun, Nov 10, 2024 at 2:00 PM Alena Rybakina
wrote:
Or maybe I was affected by fatigue, but I don’t understand this point, to be
honest. I see from the documentation and
On 02.12.2024 11:27, Alexander Korotkov wrote:
Hi, Alena!
On Wed, Nov 13, 2024 at 6:21 PM Alena Rybakina
wrote:
Updated 0001-v13 attached, as well as the diff between v12 and v13.
Thank you)
And I agree with your changes. And included them in patches.
Thank you for the updated patchset
4?
To be honest, I don't quite understand what you're suggesting. Are you
suggesting moving the explanation about the pages_frozen from the commit
message to the documentation or fixing something in the documentation
about the pages_frozen? Can you please explain?
--
Regards,
Alena Ry
On 02.12.2024 17:46, Ilia Evdokimov wrote:
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to
pgstat_update_snapshot(). Also, the tests need to be fixed.
Thank you, I'll fix it
--
Regards,
Alena Rybakina
Postgres Professional
bit so that it considers not only the quals in
jointree->quals, but also those in join expression
(subselect->jointree->fromlist). If they satisfy the conditions for
using pull up, I add them to the list of clauses and form a "Bool"
expression from them, joined by an "AND&q
but I already
found out that by changing this, the logic of correction there is
required a little more complicated. At the moment, I'm working to add
this processing to the patch.
Thanks for the case!
--
Regards,
Alena Rybakina
Postgres Professional
Thank you for updated version! I agree for your version of the code.
On 02.02.2025 21:00, Alexander Korotkov wrote:
On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
wrote:
I started reviewing at the patch and saw some output "ERROR" in the output of
the test and is it okay her
On 03.02.2025 14:32, Alexander Korotkov wrote:
On Mon, Feb 3, 2025 at 12:22 PM Alena Rybakina
wrote:
Thank you for updated version! I agree for your version of the code.
On 02.02.2025 21:00, Alexander Korotkov wrote:
On Fri, Jan 31, 2025 at 4:31 PM Alena Rybakina
wrote:
I started
On 04.02.2025 18:22, Alena Rybakina wrote:
Also, should pgstat_track_vacuum_statistics also affect
per database statistics?
According to my original idea, I thought that we could collect
extended statistics on relationships depending on whether the hook is
enabled, and always on
? Same issue, but it collects more information about the
vacuum procedure for relations and databases.
I mentioned it here [0] in the current thread.
[0]
https://www.postgresql.org/message-id/Z4U3hkWuEgByhGgJ%40ip-10-97-1-34.eu-west-3.compute.internal
--
Regards,
Alena Rybakina
Postgres
/
rel->pgstat_enabled= false;
rel->pgstat_info= NULL;
return;
}
I think I can try yo add an external parameter in the relation like
ext_vacuum_pgstat_info and determine its values depending on the guc's
pgstat_track_vacuum_statisticsvalue.
--
Regards,
Alena Rybakina
Postgres Professional
On 10.02.2025 23:51, Ilia Evdokimov wrote:
On 09.02.2025 18:14, Alena Rybakina wrote:
Hi! I found another example where the transformation worked
incorrectly and reconsidered the idea.
As for conversion of exists_sublink_to_ANY, we need to get the
flattened implicit-AND list of clauses and
e function, otherwise the code is very
repetitive in this place. I did it and attached diff file
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/backend/optimizer/plan/analyzejoins.c b/src/backend/optimizer/plan/analyzejoins.c
index d0d9b80be9c..d31427693da 100644
--
t of the test and is it okay here?
SELECT * FROM tenk1 t1
WHERE t1.thousand= 42OR t1.thousand= (SELECT t2.tenthousFROM tenk1 t2
WHERE t2.thousand= t1.tenthous);
ERROR: more than one row returned by a subquery used as an expression
--
Regards,
Alena Rybakina
Postgres Professional
ssage-id/86f76aa5-1ab5-4e2e-9b15-405051852a2a%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
rows('select b from p where c < 10 group
by b');
estimated | actual
---+
27| 29
(1row)
drop table p;
I added it in the diff file.
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/test/regress/expected/partition_prune.out b/src/test/regress/expected/part
On 10.01.2025 17:51, Alena Rybakina wrote:
Hi! I thought about this problem again and I think I have a solution.
On 02.12.2024 23:12, Alena Rybakina wrote:
* I've read the previous discussion on how important to keep all these
fields regarding vacuum statistics including points by Andre
Hi!
On 12.01.2025 21:39, Alexander Korotkov wrote:
On Fri, Nov 29, 2024 at 9:54 AM Alexander Korotkov wrote:
On Fri, Nov 29, 2024 at 7:51 AM Alena Rybakina
wrote:
On 29.11.2024 03:04, Alexander Korotkov wrote:
On Thu, Nov 28, 2024 at 9:33 PM Alena Rybakina
wrote:
On 28.11.2024 22:28
Hi! I have solved it.
On 30.12.2024 11:24, Alena Rybakina wrote:
Hi! Thank you for your interest to this subject!
On 27.12.2024 15:53, Ilia Evdokimov wrote:
Hi Alena,
Thank you for your work on subqueries with JOIN.
Have you considered the scenario where in subquery includes a qual
like
->wal_usage).
[0] https://commitfest.postgresql.org/51/5012/
--
Regards,
Alena Rybakina
Postgres Professional
101 - 200 of 265 matches
Mail list logo
