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
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
://danolivo.substack.com/p/7456653e-9716-4e91-ad09-83737784c665
--
Regards,
Alena Rybakina
Postgres Professional
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 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 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
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
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
s relkind,
you may need to use get_rel_relkind.
--
Regards,
Alena Rybakina
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
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
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
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
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
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
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
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 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
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
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 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
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
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
://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
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
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/
-> 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
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
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
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
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 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
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
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
.
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
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
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
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
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
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
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
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.
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
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
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
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
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
/052172e4-6d75-8069-3179-26de339dca03%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
si->exact_pages, si->lossy_pages);
+ }
+ else
+ {
+ ExplainPropertyInteger("Exact Heap Blocks", NULL,
si->exact_pages, es);
+ ExplainPropertyInteger("Lossy Heap Blocks", NULL,
si->lossy
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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'
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 '
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
../../../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
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
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/
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
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
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
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
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
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 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
.org/message-id/43ad8a48-b980-410d-a83c-5beebf82a4ed%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
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
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
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
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
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
1 - 100 of 148 matches
Mail list logo
