Hi, all! I updated the patch and it looks nice. All the problems have
been solved.
On 03.04.2025 16:56, Ilia Evdokimov wrote:
On 02.04.2025 19:39, Alena Rybakina wrote:
I see that I need to add a walker that, when traversing the tree,
determines whether there are conditions under which
On 02.06.2025 19:25, Alexander Korotkov wrote:
On Tue, May 13, 2025 at 12:49 PM Alena Rybakina
wrote:
On 12.05.2025 08:30, Amit Kapila wrote:
On Fri, May 9, 2025 at 5:34 PM Alena Rybakina wrote:
I did a rebase and finished the part with storing statistics separately from
the relation
w.postgresql.org/message-id/35d87371-f3ab-42c8-9aac-bb39ab5bd987%40gmail.com
https://postgr.es/m/Z4npAKvchWzKfb_r%40paquier.xyz
Greetings,
Andres Freund
--
Regards,
Alena Rybakina
Postgres Professional
Hi!
On 12.05.2025 08:30, Amit Kapila wrote:
On Fri, May 9, 2025 at 5:34 PM Alena Rybakina wrote:
I did a rebase and finished the part with storing statistics separately from
the relation statistics - now it is possible to disable the collection of
statistics for relationsh using gucs and
er place that's a better fit.
I have no immediate ideas about what that should look like, other
than it'd be better if it happened after join removal.
I didn't consider this and I'll think about it.
Thanks for the feedback!
Regards,
Alena Rybakina
Po
Specifically, we can verify that it now involves only a single relation
or partitioned relations without formation join algorithms.
I'm just studying this for the first time so apologies if this review
is not quite up to standard.
No need to apologize - you raised important points during
Hi!
On 22.04.2025 21:23, Andrei Lepikhov wrote:
On 10/28/24 14:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
If I missed something or misunderstood, can you explain in more detail?
Actually, I mean why do we need a possibility to return statistics for
all
rows=101 width=4)
(actual time=0.014..0.039 rows=101.00 loops=1)
Output:t1.x
Buffers:shared hit=1
Planning:
Buffers:shared hit=12
Planning Time:0.478 ms
Execution Time:0.293 ms
(31 rows)
--
Regards,
Alena Rybakina
Postgres Professional
I need a few days to implement this and need time for a
review, and I think I will not have time to do this before the code
freeze, so
I am moving this to the next commitfest and not changing the status
"awaiting the author".
On 11.02.2025 18:59, Alena Rybakina wrote:
On 10.02.2025 23:51,
atch with what I
have already managed to demonstrate the problem, since I need to bring
the code to a normal form.
Maybe someone who worked with the stat collector will suddenly tell me
where and what I have implemented incorrectly.
--
Regards,
Alena Rybakina
Postgres Professional
On 03.04.2025 18:26, Alexander Korotkov wrote:
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message.
Thank you, it looks fine)
Also, I've adjust regression tests by removing excessiv
I realized that I uploaded my diff file with a small mistake - sorry
about that. I've corrected it with this message so your tests can pass
in the CI.
On 31.03.2025 05:33, Alena Rybakina wrote:
Hi!
On 21.03.2025 18:56, Andrei Lepikhov wrote:
On 20/3/2025 07:02, David Rowley wrote:
O
On 12.03.2025 23:50, Peter Geoghegan wrote:
On Wed, Mar 12, 2025 at 4:28 PM Alena Rybakina
wrote:
Thank you for the explanation!
Now I see why these changes were made.
After your additional explanations, everything really became clear and I
fully agree with the current code regarding this
On 02.04.2025 22:00, Alexander Korotkov wrote:
Hi, Alena!
On Wed, Apr 2, 2025 at 5:33 PM Alena Rybakina
wrote:
I prepared a patch according to my suggestions, it just checks
that the transformation is not carried out if there is a var
element, there are changes only in one test
On 03.04.2025 02:32, Peter Geoghegan wrote:
On Tue, Apr 1, 2025 at 3:08 PM Alena Rybakina wrote:
I think it would be useful to show information that we used an index scan but at the same time we
skipped the "region" column and I assume we should output how many distinct values th
e both
test queries, since I remain of the opinion that they're likely
a waste of cycles.
Agree.
--
Regards,
Alena Rybakina
Postgres Professional
On 04.04.2025 17:39, Andres Freund wrote:
On 2025-04-03 18:26:48 +0300, Alexander Korotkov wrote:
On Thu, Apr 3, 2025 at 5:18 PM Alena Rybakina wrote:
Okay, I agree with you.
Good. I've reflected this limitation in comments and the commit
message. Also, I've adjust regressio
On 01.04.2025 17:23, Alena Rybakina wrote:
Hi, Alexander!
On 01.04.2025 15:07, Alexander Korotkov wrote:
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
4.1) explain analyze SELECT ten
FROM onek t WHERE unique1 IN ( VALUES (0), ((2 IN ( SELECT
unique2 FROM
Hi! Sorry for my later feedback, I didn't have enough time because of my
work and the conference that was held during these two days.
On 28.03.2025 23:15, Peter Geoghegan wrote:
On Thu, Mar 27, 2025 at 6:03 PM Alena Rybakina
wrote:
I replied an example like this:
This example shows
alues that the
skip array will consider during the index scan.
--
Regards,
Alena Rybakina
Postgres Professional
Hi, Alexander!
On 01.04.2025 15:07, Alexander Korotkov wrote:
Hi, Alena!
On Tue, Apr 1, 2025 at 2:11 AM Alena Rybakina
wrote:
4.1) explain analyze SELECT ten
FROM onek t WHERE unique1 IN ( VALUES (0), ((2 IN ( SELECT unique2
FROM onek c WHERE c.unique2 in ((values(0),(2
Hi, Alexander!
On 30.03.2025 00:59, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 29, 2025 at 9:03 PM Alena Rybakina
wrote:
On 29.03.2025 14:03, Alexander Korotkov wrote:
One thing I have to fix: we must do
IncrementVarSublevelsUp() unconditionally for all expressions as Vars
could be
On 31.03.2025 06:33, David Rowley wrote:
On Mon, 31 Mar 2025 at 16:21, Alena Rybakina wrote:
However, is it necessary to check that extra->inner_unique must be false for
SEMI/ANTI joins here, or am I missing something? It looks a little confusing at
this point.
If it is necessary, I do
On 31.03.2025 06:04, David Rowley wrote:
On Mon, 31 Mar 2025 at 15:33, Alena Rybakina wrote:
I believe it's worth asserting that both inner_unique and single_mode are not
true at the same time — just as a safety check.
add_paths_to_joinrel() just chooses not to populate inner_unique for
amp; (jointype== JOIN_SEMI||
jointype== JOIN_ANTI))
single_mode= true;
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/backend/optimizer/path/joinpath.c b/src/backend/optimizer/path/joinpath.c
index c75408f552b..252cb712943 100644
--- a/src/backend/optimizer/path/joinpath.c
+++ b/
Hi!
On 29.03.2025 14:03, Alexander Korotkov wrote:
On Wed, Mar 12, 2025 at 8:11 PM Alena Rybakina
wrote:
On 06.03.2025 11:23, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't w
On 28.03.2025 15:23, Alena Rybakina wrote:
I agree with your code in general, but to be honest, double qsort
confused me a little.
I understood why it is needed - we need to sort the elements so that
they stand next to each other if they can be assigned to the same
group, and then sort the
On 28.03.2025 02:18, Alexander Korotkov wrote:
Hi!
On Mon, Mar 24, 2025 at 2:46 PM Alena Rybakina
wrote:
I agree with Andrey's changes and think we should fix this, because otherwise
it might be inconvenient.
For example, without this changes we will have to have different test o
hes: 4
Buffers: shared hit=5 read=50 Planning: Buffers: shared hit=55 read=1
Planning Time: 0.984 ms Execution Time: 36.940 ms
What do you think?
I didn't see any regression tests. Maybe we should add some tests? To be
honest I didn't see it mentioned in the commit message but I might have
missed something.
--
Regards,
Alena Rybakina
Postgres Professional
mt, lc);
+
+ if (stmt->planId != UINT64CONST(0))
+ {
+ pgstat_report_plan_id(stmt->planId, false);
+ break;
+ }
+ }
+
cmdtagname = GetCommandTagNameAndLen(portal->commandTag, &cmdtaglen);
--
Regards,
Alena Rybakina
Postgres Professional
he same query for different versions of Postres in
extensions if the whole change is only related to the order of column
output for a transformation that was not applied.
--
Regards,
Alena Rybakina
Postgres Professional
Sorry, I forgot to provide a link to the problem [0], actually. So I
provided it below.
[0]
https://www.postgresql.org/message-id/CAPpHfduoJEuoixPTTg2tjhnXqrdobuMaQGxriqxJ9TjN1uxOuA%40mail.gmail.com
On 21.03.2025 22:42, Alena Rybakina wrote:
On 13.03.2025 09:42, Bertrand Drouvot wrote:
Hi
On 18.03.2025 13:54, Alena Rybakina wrote:
On 12.03.2025 23:50, Peter Geoghegan wrote:
On Wed, Mar 12, 2025 at 4:28 PM Alena Rybakina
wrote:
Thank you for the explanation!
Now I see why these changes were made.
After your additional explanations, everything really became clear and I
On 17.03.2025 09:42, vignesh C wrote:
On Thu, 27 Feb 2025 at 23:30, Alena Rybakina wrote:
Hi!
On 17.02.2025 17:46, Alena Rybakina wrote:
On 04.02.2025 18:22, Alena Rybakina wrote:
Hi! Thank you for your review!
On 02.02.2025 23:43, Alexander Korotkov wrote:
On Mon, Jan 13, 2025 at 3:26 PM
On 12.03.2025 01:59, Peter Geoghegan wrote:
On Tue, Mar 11, 2025 at 6:24 PM Alena Rybakina
wrote:
Hi, reviewing the code I noticed that you removed the
parallel_aware check for DSM initialization for BitmapIndexScan,
IndexScan, IndexOnlyScan,
but you didn't do the same i
ime to get to know this commit yet. How will
this statistic help us analyze the work of the vacuum for relations?
--
Regards,
Alena Rybakina
Postgres Professional
Hi!
On 10.03.2025 16:33, Kirill Reshke wrote:
On Thu, 27 Feb 2025 at 23:00, Alena Rybakina wrote:
Hi!
On 17.02.2025 17:46, Alena Rybakina wrote:
On 04.02.2025 18:22, Alena Rybakina wrote:
Hi! Thank you for your review!
On 02.02.2025 23:43, Alexander Korotkov wrote:
On Mon, Jan 13, 2025 at
Hi, Alexander!
On 06.03.2025 11:23, Alexander Korotkov wrote:
Hi, Alena!
On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina wrote:
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like
ld the check be removed in the
ExecParallelReInitializeDSM function too?
--
Regards,
Alena Rybakina
Postgres Professional
On 06.03.2025 17:13, Robert Haas wrote:
On Thu, Mar 6, 2025 at 8:30 AM Matthias van de Meent
wrote:
On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote:
Hi! I got a query plan with a strange number of rows. Could you please
help me understand it?
To be honest I can't understand why
On 06.03.2025 16:30, Matthias van de Meent wrote:
On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote:
Hi! I got a query plan with a strange number of rows. Could you please
help me understand it?
To be honest I can't understand why 0.50 number of rows here?
Because the scan matched only
ows=0.50 loops=999)
Filter: (id = ta1.id)
Rows Removed by Filter: 375
-> Seq Scan on tc (actual rows=1.00 loops=500)
(15 rows)
To be honest I can't understand why 0.50 number of rows here?
--
Regards,
Alena Rybakina
Postgres Professional
On 03.03.2025 14:17, Alena Rybakina wrote:
Hi! Thank you for your work on this subject.
I agree with your code but one phrase in commit message was confusing
for me:
"This change is dedicated to more active usage of IndexScan and
parameterised
NestLoop paths in partitioned cases und
plain tables."
As I understood this thread is about the optimization that allows
considering Index Scan if we need the limited number of rows and
later the commit message contains it. I didn't understand completely the
sentence above to be honest.
--
Regards,
Alena Rybakina
Postgres Professional
[0] https://github.com/postgrespro/aqo
--
Regards,
Alena Rybakina
Postgres Professional
On 28.02.2025 14:48, Alena Rybakina wrote:
Hi!
On 21.02.2025 00:09, Alena Rybakina wrote:
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) cou
Hi!
On 21.02.2025 00:09, Alena Rybakina wrote:
Hi!
On 09.02.2025 18:38, Alexander Korotkov wrote:
Also, aren't we too restrictive while requiring is_simple_values_sequence()?
For instance, I believe cases like this (containing Var) could be transformed
too.
select * from t t1, la
cost=0.00..1443.00 rows=10 width=32)
I have implemented a patch that solves this problem - allowing to
consider and join expressions for trial optimization. I am glad for
feedback and review!
--
Regards,
Alena Rybakina
Postgres Professional
From eb8fe49f68e198217a8f3e92ee424ff897f9e21e Mon Sep
to a type suitable for the found operator.
--
Regards,
Alena Rybakina
Postgres Professional
From 252e6a0b9a0b187e21a0721931f185d20061e66f Mon Sep 17 00:00:00 2001
From: Alena Rybakina
Date: Thu, 20 Feb 2025 23:30:01 +0300
Subject: [PATCH 2/2] Add an implementation of the x IN VALUES to 'x =
025 12:19, Alexander Korotkov wrote:
On Thu, Feb 13, 2025 at 1:00 AM Alexander Korotkov wrote:
On Tue, Feb 11, 2025 at 5:31 PM Alena Rybakina
wrote:
Hi! Thank you for the work with this subject, I think it is really
important.
On 10.02.2025 22:58, Alexander Korotkov wrote:
Hi!
On Mon, Feb
that.
The precedent to follow here is "Heap Fetches: N" (in the context of
index-only scans), which also doesn't divide by nloops. Likely because
the same sorts of issues arise with heap fetches.
Yes, you are right, I agree with both of you.
--
Regards,
Alena Rybakina
Postgres Professional
ing the query plans -
I think there is a lack of a description of the reason why this is done
in the commit message.
I would also add the same to the documentation with an example.
--
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
--
Hi! Thank you for your review!
On 09.02.2025 18:38, Alexander Korotkov wrote:
On Sun, Feb 9, 2025 at 1:58 PM Alexander Korotkov wrote:
On Thu, Jan 9, 2025 at 3:11 PM Alena Rybakina wrote:
On 04.10.2024 12:05, Andrei Lepikhov wrote:
We also have an implementation of VALUES -> AR
cases.
--
Regards,
Alena Rybakina
Postgres Professional
From 9f42dc0bbe1899751892a67355fe447d917096a4 Mon Sep 17 00:00:00 2001
From: Alena Rybakina
Date: Mon, 27 Jan 2025 22:31:47 +0300
Subject: [PATCH] Add appling the pull-up transformation for expressions. We
examine all expressions and need t
/
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 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
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
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
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
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 15.01.2025 23:09, Melanie Plageman wrote:
On Wed, Jan 15, 2025 at 12:08 PM Alena Rybakina
wrote:
This is interesting, but I think it might belong as commentary in
vacuumparallel.c instead.
I added some description about it, I hope it is fine. I attached
vacuum_description.diff
Alena
unclear how the data would be
interpreted in the future. For instance, a query that genuinely impacted
performance might not be processed by pg_stat_statements simply due to
randomness, while a small, insignificant query could be selected
instead. Analyzing such statistical information might
On 14.01.2025 22:51, Melanie Plageman wrote:
On Mon, Jan 13, 2025 at 5:37 PM Alena Rybakina
wrote:
Thank you for working on this patch, without this explanation it is difficult
to understand what is happening, to put it mildly.
Thanks for the review! I've incorporated most of them
lated. It is not clear what the below condition means.
/* -1 is used to disable max threshold */
vac_max_thresh= (relopts&& relopts->vacuum_max_threshold>= -1)
? relopts->vacuum_max_threshold
: autovacuum_vac_max_thresh;
--
Regards,
Alena Rybakina
Postgres Professional
groups. I
think it is okay for these four to remain in their current locations
as their current groupings seem descriptive enough.
Looking at them, I am willing to agree with you
--
Regards,
Alena Rybakina
Postgres Professional
open to feedback.
Looks good and convenient, thanks for the patch!
I noticed another guc autovacuum_work_mem, which belongs more to the
autovacuum category in my opinion, although it belongs to RESOURCES_MEM,
but in fact, only autovacuum uses it.
--
Regards,
Alena Rybakina
Postgres Professional
->wal_usage).
[0] https://commitfest.postgresql.org/51/5012/
--
Regards,
Alena Rybakina
Postgres Professional
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
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
Sorry, I made a typo due to lack of sleep, I've marked below where
exactly just in case.
On 10.01.2025 15:04, Alena Rybakina wrote:
Hi, I have updated the patch. Fix minor mistakes in the document,
added the wraparound_failsafe_count statistics - it accounts the
number of times whe
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 Andrei and Jim.
It still worrying me that stati
ves a complete picture of vacuum efficiency, because
analyzing only total_time statistics does not give a complete picture of
what vacuum did: was it cleaning almost huge index, cleaning tables or
just sleeping.
[0] https://commitfest.postgresql.org/51/5012/
--
Regards,
Alena Rybakina
Pos
le_rate;
else
current_query_sampled = false;
}
I think you should put this in a function like
update_current_query_sampled. I've attached a diff file with the changes.
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/contrib/pg_stat_statements/expected/
and right
sides, and after that make a coercion.
This processing is only needed in cases where we are not working with
parameters since the final type is not specified for the parameters.
--
Regards,
Alena Rybakina
Postgres Professional
From bb8c51ee50739373f23e97421e78afff8734210e Mon Sep 17 0
spent in total on processing
indexes, since indexes can be bloated, for example. I think it is better
to leave these statistics here.
--
Regards,
Alena Rybakina
Postgres Professional
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
On 24.12.2024 13:25, Ranier Vilela wrote:
Hi Alena.
Em ter., 24 de dez. de 2024 às 01:44, Alena Rybakina
escreveu:
Hi, hackers!
I found one pull-up that works if the inner join condition is
written through the where condition,
|create temp table ta (id int primary key, val
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
ssage-id/86f76aa5-1ab5-4e2e-9b15-405051852a2a%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
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
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 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
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
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
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&
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
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.
: 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
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 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
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
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
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
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
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
1 - 100 of 267 matches
Mail list logo
