path,
cheapest_path,
info->pathkeys);
if (path == NULL)
continue;
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/optimizer/path/pathkeys.c b/src/back
On 26.01.2024 05:37, vignesh C wrote:
On Tue, 24 Oct 2023 at 01:47, Alena Rybakina wrote:
Hi!
I looked through your patch and noticed that it was not applied to the current
version of the master. I rebased it and attached a version. I didn't see any
problems and, honestly, no big ch
x27;m suggesting this because of the set_join_pathlist_hook
function, which is in the add_paths_to_joinrel function, which allows
you to create a custom node. What do you think?
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
25 rows=23 width=10)
Output: 2, ctid
Filter: (foo.f1 = ANY ('{1,2}'::integer[]))
(4 rows)
Maybe I missed something. Do you have any examples?
* some other minor cosmetic changes.
Thank you, I agree with them.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 01.02.2024 08:00, jian he wrote:
On Wed, Jan 31, 2024 at 7:10 PM Alena Rybakina
wrote:
Hi, thank you for your review and interest in this subject.
On 31.01.2024 13:15, jian he wrote:
On Wed, Jan 31, 2024 at 10:55 AM jian he wrote:
based on my understanding of
https
si->exact_pages, si->lossy_pages);
+ }
+ else
+ {
+ ExplainPropertyInteger("Exact Heap Blocks", NULL,
si->exact_pages, es);
+ ExplainPropertyInteger("Lossy Heap Blocks", NULL,
si->lossy
fo1) variable, so maybe we should run it after the
make_restrictonfo procedure, otherwise calling it, I think, is useless.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 12.02.2024 12:01, Andrei Lepikhov wrote:
On 12/2/2024 15:55, Alena Rybakina wrote:
Hi!
I can't unnderstand this part of code:
/* Time to generate index paths */
MemSet(&clauseset, 0, sizeof(clauseset));
match_clauses_to_index(root, list_make1(rinfo1), index, &clauseset);
As
Hi! Sorry my delayed reply too.
On 17.01.2024 12:33, Yuya Watari wrote:
Hello Alena,
Thank you for your quick response, and I'm sorry for my delayed reply.
On Sun, Dec 17, 2023 at 12:41 AM Alena Rybakina
wrote:
I thought about this earlier and was worried that the index links o
all?
alena@postgres=# SELECT relname, relkind FROM pg_class where
relname='itrtest';
relname | relkind
-+-
itrtest | p
(1 row)
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e author of the corrections is not only me, but also Daniil Anisimov.
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/optimizer/util/clauses.c
b/src/backend/optimizer/util/clauses.c
index edc25d712e9..ac560b1605e 1
ntioned by others.
You can further furnish it.
Thank you for your work. I found a few spelling mistakes - I fixed this
and added some information about generating a partial index plan. I
attached it.
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgr
On 28.02.2024 13:07, jian he wrote:
On Wed, Feb 28, 2024 at 12:19 PM Andrei Lepikhov
wrote:
On 26/2/2024 11:10, Alena Rybakina wrote:
On 24.02.2024 14:28, jian he wrote:
Hi.
I wrote the first draft patch of the documentation.
it's under the section: Planner Method Configuration
(ru
eb 29, 2024 at 10:59 AM Andrei Lepikhov
wrote:
On 28/2/2024 17:27, Alena Rybakina wrote:
> Maybe like that:
>
> It also considers the way to generate a path using BitmapScan
indexes,
> converting the transformed expression into expressions separated
by &quo
Sorry, I found explanation -
https://www.postgresql.org/message-id/CACJufxFS-xcjaWq2Du2OyJUjRAyqCk12Q_zGOPxv61sgrdpw9w%40mail.gmail.com
On 03.03.2024 12:26, Alena Rybakina wrote:
I found that it was mentioned here -
https://www.postgresql.org/message-id
To be honest, I didn't see it in the code, could you tell me where they
are, please?
On 05.03.2024 05:44, Richard Guo wrote:
On Tue, Jan 30, 2024 at 2:51 PM Alena Rybakina
wrote:
I have reviewed your patch and I think it is better to add an
Assert for
JOIN_RIGHT_SEMI t
Bitmap Heap Scan on onek2
Recheck Cond: (stringu1 < 'B'::name)
Filter: ((stringu1 = ANY ('{A,A}'::name[])) AND (stringu1 = 'A'::name))
-> Bitmap Index Scan on onek2_u2_prtl
(4 rows)
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgre
On 06.03.2024 05:23, wenhui qiu wrote:
Hi Alena Rybakina
For merge join
+ /*
+ * For now we do not support RIGHT_SEMI join in mergejoin.
+ */
+ if (jointype == JOIN_RIGHT_SEMI)
+ {
+ *mergejoin_allowed = false;
+ return NIL
we see about 40% of
execution and 100% of planning speedup.
To avoid unnecessary overhead, induced by the optimization, such
transformation may be made at the stage of planning (we have
cardinality estimations and have pruned partitions) but before
creation of a relation scan paths. So, we can avoid planning overhead
and non-optimal BitmapOr in the case of many OR's possibly aggravated
by many indexes on the relation.
For example, such operation can be executed in create_index_paths()
before passing rel->indexlist.
--
Alena Rybakina
Postgres Professional
NG: invalid input syntax for type bytea
WARNING: invalid input syntax for type bytea
WARNING: invalid hexadecimal data: odd number of digits
WARNING: 3 rows were skipped due to data type incompatibility
COPY 1
postgres=# select * from t;
id | b
+
5 | \x
(1 row)
--
---
Alena Rybakina
Postgres Professional
estloop_path(root, joinrel, outerpath, matpath,
pathkeys, jointype, extra);
--
Regards,
Alena Rybakina
add assert in reparameterize_pathlist_by_child function that
pathlist is not a NIL, because according to the comment it needs to be
added there:
Returns NIL to indicate failure, so pathlist had better not be NIL.
--
Regards,
Alena Rybakina
but to be honest, I haven't been able
to come up with something yet.
--
Regards,
Alena Rybakina
From f7a8ca7f3263fa5f82056f90231cf937133622c9 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Mon, 23 Oct 2023 22:54:04 +0300
Subject: [PATCH] WIP: Evaluate arguments of correlated
u, and we can indeed directly set the param_info value to
NULL, and there are enough comments here to explain.
I didn't find anything else to add in your patch.
--
Regards,
Alena Rybakina
inmax_only parameter is
set by the user, so both ways are possible.
0 -
https://www.postgresql.org/message-id/62d16845-e74e-a6f9-9661-022e44f48922%40inbox.ru
--
Regards,
Alena Rybakina
Hi! Thank you for your feedback!
On 25.10.2023 22:54, Robert Haas wrote:
On Sat, Oct 14, 2023 at 6:37 PM Alexander Korotkov wrote:
Regarding the GUC parameter, I don't see we need a limit. It's not
yet clear whether a small number or a large number of OR clauses are
more favorable for transfo
On 26.10.2023 22:58, Robert Haas wrote:
On Thu, Oct 26, 2023 at 3:47 PM Alena Rybakina
wrote:
With small amounts of "OR" elements, the cost of orexpr is lower than with
"ANY", on the contrary, higher.
Alexander's example seems to show that it's not that simp
On 25.10.2023 18:35, Andrei Zubkov wrote:
Hi Alena,
On Wed, 2023-10-25 at 16:25 +0300, Alena Rybakina wrote:
Hi! Thank you for your work on the subject.
1. I didn't understand why we first try to find pgssEntry with a
false top_level value, and later find it with a true top_level value
)->subpath->parent->cheapest_startup_path
$16 = (IndexPath *) 0x555febc66160
I know it doesn't cause a crash anywhere, but can anybody explain me
what's going on here and why Invalid Path appears?
--
Regards,
Alena Rybakina
option is not to process Expr types (already mentioned earlier)
in the queries that Alexander gave as an example, but as I already said,
I don't like this approach very much.
--
Regards,
Alena Rybakina
Postgres Professional
7f7f}
(gdb)
The same problem may be in the add_partial_path() function.
Unfortunately, I have not yet been able to find a problematic query with
the described case, but I have prepared a patch to fix this problem.
What do you think?
0.
https://www.postgresql.org/messag
onversion. I don't think it
can be serious, but I haven't figured out where the mistake is yet.
I added log like that: ERROR: unrecognized node type: 0.
--
Regards,
Alena Rybakina
Postgres Professional
From 3062a2408af258b9e327219020221b75501e8530 Mon Sep 17 00:00:00 2001
From: Alen
On 06.11.2023 16:51, Alena Rybakina wrote:
I also support this approach. I have almost finished writing a patch
that fixes the first problem related to the quadratic complexity of
processing expressions by adding a hash table.
I also added a check: if the number of groups is equal to the
a choice to run copy with and
without saving errors and at the same time immediately check whether the
option with error output is possible for him in principle?
--
Regards,
Alena Rybakina
es (1, 1), (2, 2)) as t (a, b) where a
= b group by cube(a, (a, b)) order by b,a; a | b ---+--- 1 | 1 1 | 1 2 |
2 2 | 2 1 | 2 | | (7 rows)
--
Regards,
Alena Rybakina
ll be more invasive. In addition, I have added changes
related to the hash table: now the key is of type int.
All changes are displayed in the attached
v9-0001-Replace-OR-clause-to_ANY.diff.txt file.
I haven't measured it yet. But what do you think about these changes?
--
Regards,
Alena Ry
On 21.11.2023 03:50, Alena Rybakina wrote:
On 20.11.2023 11:52, Andrei Lepikhov wrote:
Looking into the patch, I found some trivial improvements (see
attachment).
Also, it is not obvious that using a string representation of the
clause as a hash table key is needed here. Also, by making a copy
ressed the expression evaluation
procedure to make regression test changes more clear.
Thank you for your work. You are right, the patch with the current
changes looks better and works more correctly.
To be honest, I didn't think we could use JumbleExpr in this way.
--
Regards,
Alena Ry
.org/message-id/43ad8a48-b980-410d-a83c-5beebf82a4ed%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
On 24.11.2023 13:20, Alena Rybakina wrote:
Hi! Thank you for your work on the subject, I think it's a really
useful feature.
I've reviewed your patch and I have a few questions.
First of all, have you thought about creating a gun parameter to
display memory scheduling informatio
ct
bitmap index scans. So, in the example [1] and similar queries
conversion of OR-expressions to ANY wouldn't affect the generation of
bitmap paths.
Thanks for the explanation, yes, I did not understand the idea correctly
at first. I will try to implement something similar.
--
Regards,
Ale
On 25.11.2023 19:13, Alexander Korotkov wrote:
On Sat, Nov 25, 2023 at 1:10 PM Alena Rybakina
wrote:
On 25.11.2023 04:13, Alexander Korotkov wrote:
It seems to me there is a confusion. I didn't mean we need to move
conversion of OR-expressions to ANY into choose_bitmap_and() functi
60 rows=1 width=0)
-> Bitmap Index Scan on test_x_1_y (cost=0.00..4.30 rows=1
width=0)
Index Cond: (y = '100'::double precision)
-> Bitmap Index Scan on test_x_2_y (cost=0.00..4.30 rows=1
width=0)
Index Cond: (y = '100'::double precision)
(7 rows)
--
Regards,
Alena Rybakina
Postgres Professional
Sorry, I forgot to apply my patches. For the first experiment was
0001-OR-to-ANY-in-parser-and-ANY-to-OR-in-index.diff and for the second
experiment was 0002-OR-to-ANY-in-index.diff.
On 30.11.2023 11:00, Alena Rybakina wrote:
Hi!
Honestly, it seems very hard to avoid the conclusion that
On 30.11.2023 11:30, Andrei Lepikhov wrote:
On 30/11/2023 15:00, Alena Rybakina wrote:
2. The second patch is my patch version when I moved the OR
transformation in the s index formation stage:
So, I got the best query plan despite the possible OR to ANY
transformation:
If the user uses a
On 30.11.2023 11:00, Alena Rybakina wrote:
Hi!
Honestly, it seems very hard to avoid the conclusion that this
transformation is being done at too early a stage. Parse analysis is
not the time to try to do query optimization. I can't really believe
that there's a way to produce a c
s/sql/multirangetypes.sql and
src/test/regress/sql/rangetypes.sql.
I added a few in the attached patch.
--
Regards,
Alena Rybakina
diff --git a/src/backend/utils/adt/multirangetypes_selfuncs.c
b/src/backend/utils/adt/multirangetypes_selfuncs.c
index c670d225a0c..7708768b89f 100644
--- a/src/backend/
of the
err_sp.error_rel table.
5. Is this part of the comment needed? I think it duplicates the
information below when we form the query.
* . column list(order by attnum, begin from ctid) =
* {ctid, lineno,line,field,source,err_message,err_detail,errorcode}
* . data types (from att
../../../src/Makefile.global:783: gram.c] Error 1
make[1]: *** [Makefile:131: parser/gram.h] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [src/Makefile.global:383: submake-generated-headers] Error 2
I have ubuntu 22.04 operation system.
On 06.12.2023 13:47, jian he wrote:
On Tu
that can
lead to executor crashes, wrong results, or planning errors, as we have
already seen.
I marked it as 'Ready for Committer'. I think it is ready.
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi! Thank you for your work. Your patch looks better!
On 10.12.2023 13:32, jian he wrote:
On Fri, Dec 8, 2023 at 3:09 PM Alena Rybakina wrote:
Thank you for your work. Unfortunately, your code contained errors during the
make installation:
'SAVEPOINT' after '
On 12.12.2023 16:04, jian he wrote:
On Mon, Dec 11, 2023 at 10:05 PM Alena Rybakina
wrote:
Hi! Thank you for your work. Your patch looks better!
Yes, thank you! It works fine, and I see that the regression tests have been
passed. 🙂
However, when I ran 'copy from with save_error'
APpHfdseB13zJJPZuBORevRnZ0vcFyUaaJeSGfAysX7S5er%2BEQ%40mail.gmail.com
Yes, I also thought in this direction before and I agree that this is
the best way to develop the patch.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
nce on this optimization. So, we can avoid to call the
* build_joinrel_restrictlist() routine.
*/
restrictlist = generate_join_implied_equalities(root, joinrelids,
inner->relids,
outer, NULL);
--
Regards,
Alena Rybakina
diff --git a/src/backend/o
t IS NOT NULL) AND (t <= b.t)
AND (x = b.x))
Heap Fetches: 1000
Buffers: shared hit=3000
Planning Time: 0.689 ms
Execution Time: 68.220 ms
(23 rows)
If you noticed, it became possible after replacing the "in" operator
with "=&quo
I took the liberty of adding this to your patch and added myself
as reviewer, if you don't mind.
Sure, the patch after your modification looks better than the original.
I'm not sure how the test case around "because of got one row" is
relevant to the current change
review!
Thank you!) I am ready to discuss it.
Actually I meant to discuss the "Unfortunately, I found a request..",
looks
we have reached an agreement there:)
Yes, we have)
--
Regards,
Alena Rybakina
diff --git a/src/test/regress/expected/subselect.out b/src/test/regress/expected/
written in explain.c and no functions
in explain.h have comments in it.
Regards,
--
Alena Rybakina
Postgres Professional
Hi!
On 11.06.2024 16:09, Alena Rybakina wrote:
On 08.06.2024 09:30, Alena Rybakina wrote:
Iam currentlyworkingondividingthispatchintothreepartstosimplifythe
reviewprocess:oneofthemwillcontaincodeforcollectingvacuumstatisticsontables,the
secondonindexesandthe lastondatabases.
I have
I have written the documentary and attached the patch.
On 08.06.2024 09:30, Alena Rybakina wrote:
Iam currentlyworkingondividingthispatchintothreepartstosimplifythe
reviewprocess:oneofthemwillcontaincodeforcollectingvacuumstatisticsontables,the
secondonindexesandthe lastondatabases.I
x27;100'::double precision) (7 rows)
[0] https://www.postgresql.org/message-id/3604469.1712628736%40sss.pgh.pa.us
[1]
https://www.postgresql.org/message-id/CAPpHfduJtO0s9E%3DSHUTzrCD88BH0eik0UNog1_q3XBF2wLmH6g%40mail.gmail.com
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 17.06.2024 15:11, Alexander Korotkov wrote:
On Mon, Jun 17, 2024 at 1:33 PM Alena Rybakina
wrote:
I noticed that 7 libraries have been added to
src/backend/optimizer/plan/initsplan.c, and as far as I remember, Tom Lane has
already expressed doubts about the approach that requires adding
.
But I couldn't find information, when you told about cycling a
long-expression on each incoming tuple. Could you ask me what function
you were talking about or maybe functionality? I saw ExecSeqScan
function, but I didn't see it.
--
Regards,
Alena Rybakina
Postgres Profess
g about or maybe functionality? I saw ExecSeqScan
function, but I didn't see it.
On 18.06.2024 13:05, Alena Rybakina wrote:
Hi! Unfortunately,Iwas notableto fullyunderstandyourmessage.Couldyou
explainit to meplease?
On 09.04.2024 16:20, Andrei Lepikhov wrote:
Moreover, it hel
eto review it[3]
andhisfirstparthasn'tchangedmuchsincethen.
IfIwroteto the wrongpersonaboutit,thenpleasetellme where.
[1] https://commitfest.postgresql.org/48/4450/
[2] https://commitfest.postgresql.org/48/5037/
[3]
https://www.postgresql.org/message-id/b301dce1-09fd-72b1-834a-527ca428db5e%40yandex.ru
--
Reg
On 21.06.2024 23:35, Robert Haas wrote:
On Fri, Jun 21, 2024 at 1:05 PM Alena Rybakina
wrote:
I'm confused, I have seen that we have two threads [1] and [2] about this
thread and I haven't found any explanation for how they differ.
And I don't understand, why am I not liste
digging why I got the similar behavior without replica when I have only
one instance. I'm stillcheckingthisinmytest,butI
believethispatchfixesthe originalproblembecausethesymptomswerethesame.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 24.06.2024 17:37, Melanie Plageman wrote:
On Mon, Jun 24, 2024 at 4:10 AM Alena Rybakina wrote:
We can fix this by always removing tuples considered dead before
VacuumCutoffs->OldestXmin. This is okay even if a reconnected standby
has a transaction that sees that tuple as alive, because
On 24.06.2024 18:28, Robert Haas wrote:
On Fri, Jun 21, 2024 at 6:52 PM Alena Rybakina
wrote:
It's hard to tell, but I think it might be one of the good places to apply
transformation. Let me describe a brief conclusion on the two approaches.
This explanation is somewhat difficult for
2024 at 7:14 PM Alena Rybakina
wrote:
Sorry, you are right and I'll try to explain more precisely. The first approach is the
first part of the patch, where we made "Or" expressions into an SAOP at an
early stage of plan generation [0], the second one was the one proposed by A
-> Bitmap Index Scan on a_idx (cost=0.00..8.58 rows=2 width=0)
Index Cond: (a = ANY ('{5,4}'::integer[]))
-> Bitmap Index Scan on b_idx (cost=0.00..4.29 rows=1 width=0)
Index Cond: (b = 1)
(7 rows)
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
e codeyoumentioned.
Pleasewriteifthisis notthelogicthatyouhave seenbefore.
[0]
https://www.postgresql.org/message-id/3381819.e9J7NaK4W3%40thinkpad-pgpro
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/optimizer/plan/
On 27.06.2024 23:06, Alena Rybakina wrote:
Tobe honest,I've alreadystartedwritingcodetodothis,butI'm facedwitha
misunderstandingof howto correctlycreatea
conditionfor"OR"expressionsthatare notsubjectto transformation.
For example,the expressions b=1in the query be
://www.postgresql.org/message-id/9736220.CDJkKcVGEf%40thinkpad-pgpro
[2]
https://www.postgresql.org/message-id/2193851.QkHrqEjB74%40thinkpad-pgpro
On 09.07.2024 04:57, Alena Rybakina wrote:
Hi! Thank you for your review! Sorryforthe delayin responding.
Irewrotethe patchasyourequested,butnowI'm facedwi
Sorry for repeating, but I have noticed that this message displays
incorrectly and just in case I'll duplicate it.
On 11.07.2024 19:17, Alena Rybakina wrote:
The errorwascausedby the specificsof storingthe "OR"clausesinthe
RestrictInfostructure.Scanning the orclauses list of t
I agreed with the changes. Thank you for your work.
I updated patch and added you to the authors.
I specified Ranier Vilela as a reviewer.
On 10.07.2023 06:12, Andrey Lepikhov wrote:
On 7/7/2023 15:20, Alena Rybakina wrote:
because we will provide similar manipulation in this:
foreach(l
> Hash (cost=722.00..722.00 rows=5 width=8) (actual
time=22.546..22.548 rows=5 loops=1)
Buckets: 65536 Batches: 1 Memory Usage: 2466kB
-> Seq Scan on small (cost=0.00..722.00 rows=5 width=8)
(actual time=0.006..7.218 rows=5 loops=1)
Planning Time: 0.2
Hi!
On 10.07.2023 15:15, Ranier Vilela wrote:
Em seg., 10 de jul. de 2023 às 09:03, Ranier Vilela
escreveu:
Hi Alena,
Em seg., 10 de jul. de 2023 às 05:38, Alena Rybakina
escreveu:
I agreed with the changes. Thank you for your work.
I updated patch and added
On 11.07.2023 16:29, Ranier Vilela wrote:
Em ter., 11 de jul. de 2023 às 09:29, Alena Rybakina
escreveu:
Hi!
On 10.07.2023 15:15, Ranier Vilela wrote:
Em seg., 10 de jul. de 2023 às 09:03, Ranier Vilela
escreveu:
Hi Alena,
Em seg., 10 de jul. de 2023 às 05
I suppose that this may not be the only unstable behavior - I
suppose we need sorting result elements on the left side, what do you think?
--
Regards,
Alena Rybakina
Postgres Professional
diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index cc229
Hi,
I'm still working on it, but, unfortunately, I didn't have much time to
work with it well enough that there would be something that could be shown.
Now I am trying to sort out the problems that I drew attention to in the
previous letter.
--
Regards,
Alena Rybakina
Postgres Professional
Hi, all!
I sent a patch to commitfest and noticed that the authors and the
reviewer were incorrectly marked.
Sorry about that. I fixed it and sent the current version of the patch.
--
Regards,
Alena Rybakina
Postgres Professional
From 087125cc413429bda05f22ebbd51115c23819285 Mon Sep 17 00:00
Hi!
On 26.07.2023 02:47, Peter Geoghegan wrote:
On Thu, Jun 29, 2023 at 2:32 AM Alena Rybakina wrote:
Hi! I'm sorry I didn't answer you right away, I was too busy with work.
Same for me, this time. I was busy working on my patch, which I
finally posted yesterday.
I'm glad t
n "AND" expressions to "OR" expressions, but would it be
possible to apply such a procedure earlier? Otherwise I suppose you
could face the problem of
incorrect selectivity of the calculation and, consequently, the
cardinality calculation?
I can't clearly understand at w
ted array. I'll double-check it just in case and write
about the results later.
I am also testing some experience with multi-column indexes using SAOPs.
--
Regards,
Alena Rybakina
Postgres Professional
On 02.08.2023 21:58, Peter Geoghegan wrote:
On Wed, Aug 2, 2023 at 8:58 AM Alena Rybakina wrote:
No, I haven't thought about it yet. I studied the example and it would
really be nice to add optimization here. I didn't notice any problems
with its implementation. I also have an obvio
nclusion that 500 is the ideal value for
or_transform_limit.
[0]
https://www.postgresql.org/message-id/919bfbcb-f812-758d-d687-71f89f0d9a68%40postgrespro.ru
[1]
https://www.postgresql.org/message-id/6b97b517-f36a-f0c6-3b3a-0cf8cfba220c%40yandex.ru
--
Regards,
Alena Rybakina
Postgres Professional
/052172e4-6d75-8069-3179-26de339dca03%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
d_rate and write_rate now include local block usage
- I've added a specific output for reporting local blocks instead of
combining them in the same output.
Regards,
Anthonin
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
On 22.04.2024 11:07, Anthonin Bonnefoy wrote:
On Sat, Apr 20, 2024 at 2:00 PM Alena Rybakina
wrote:
Hi, thank you for your work with this subject.
While I was reviewing your code, I noticed that your patch
conflicts with another patch [0] that been committed.
[0]
https
st in case, I'll explain: I considered this case because your patch
could have impact influenced it too.
On 25.04.2024 10:17, Anthonin Bonnefoy wrote:
On Wed, Apr 24, 2024 at 4:01 PM Alena Rybakina
wrote:
I tested the main postgres branch with and without your fix using
a
Hi!
On 30.04.2024 05:18, Masahiko Sawada wrote:
On Fri, Apr 26, 2024 at 9:12 PM Alena Rybakina wrote:
Hi!
The same script was run, but using vacuum verbose analyze, and I saw the
difference again in the fifth step:
with your patch: buffer usage: 32312 hits, 607 misses, 1566 dirtied
master
uffers() function, see comment:
/*
* Skip this block if someone else has already completed it. If an
* I/O is already in progress in another backend, this will wait for
* the outcome: either done, or something went wrong and we will
* retry.
*/
--
Re
ing is the number of tuples
returned from the node, that causes it to double-count those tuples.
The more duplicate-keyed tuples on the outer side, the bigger the
effect.
You can see the same thing happening at the Materialize a little
further up, which is feeding the inside of the other merge join.
effect of overhead on the
system at the strategic level, the vacuum has gathered this information
already, but this valuable information doesn't store it.
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 30.05.2024 10:33, Alena Rybakina wrote:
I suggest gathering information about vacuum resource consumption for
processing indexes and tables and storing it in the table and index
relationships (for example, PgStat_StatTabEntry structure like it has
realized for usual statistics). It will
Ok, I get it.
Since GetLockMethodLocalHash() is only used for assertions, this is
only defined when USE_ASSERT_CHECKING is enabled. This patch uses
GetLockMethodLocalHash() not only for the assertion purpose, so I
removed "ifdef USE_ASSERT_CHECKING" for this function. I belive it
does not le
I'm sorry I was unable to respond right away.
On 09.05.2023 17:23, torikoshia wrote:
You may already understand it, but these variable names are given in
imitation of FREEZE and BINARY cases:
--- a/src/include/commands/copy.h
+++ b/src/include/commands/copy.h
@@ -42,6 +42,7 @@ typedef st
I'm sorry I was unable to respond right away.
On 09.05.2023 17:23, torikoshia wrote:
You may already understand it, but these variable names are given in
imitation of FREEZE and BINARY cases:
--- a/src/include/commands/copy.h
+++ b/src/include/commands/copy.h
@@ -42,6 +42,7 @@ typedef st
the current join, and clamp with those in
the same way as for the base relations.*
1.
https://www.postgresql.org/message-id/flat/5156.1314829311%40sss.pgh.pa.us#86609b6ac6af405dec67316bfbe9868f
2. https://www.postgresql.org/message-id/raw/5156.1314829311%40sss.pgh.pa.us
Regards,
Alena Rybakina
1 - 100 of 265 matches
Mail list logo
