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.
--
Rega
:
/*
* 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.
*/
--
Regards,
Alena Rybakina
Postgres
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
, 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 script
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
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
>lossy_pages);
+ }
+ else
+ {
+ ExplainPropertyInteger("Exact Heap Blocks", NULL,
si->exact_pages, es);
+ ExplainPropertyInteger("Lossy Heap Blocks", NULL,
si->lossy_pages, es);
+ }
+
+
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
< '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.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/parser/parse_expr.c b/
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
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
, 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 "OR&
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
(runtime
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 Postgres Company
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 100644
--- a/src
re
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
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(, 0, sizeof(clauseset));
match_clauses_to_index(root, list_make1(rinfo1), index, );
As I understand
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
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
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 changes
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/backend/optimizer/path/p
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' operation
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 'SAVE_ERROR
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
] 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 Tue, Dec 5, 2023 at 6:07 PM Alena Rybakina
er by attnum, begin from ctid) =
* {ctid, lineno,line,field,source,err_message,err_detail,errorcode}
* . data types (from attnum = -1) ={tid,
int8,text,text,text,text,text,text}
I'm not sure if we need to order the rows by number. It might be easier
to work with these lines in the orde
/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/utils
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 committable
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
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
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() function
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,
Alena Rybakina
Postgres
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 information? I agree
/43ad8a48-b980-410d-a83c-5beebf82a4ed%40postgrespro.ru
--
Regards,
Alena Rybakina
Postgres Professional
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 Rybakina
Postgres
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
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 Rybakina
Postgres
- 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
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
'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: Alena Rybakina
Date: Mon, 6 Nov 2023 16:48:00 +0300
Subject: [PATCH] Repl
lem 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/message-id/flat/01aa76cc-93e1-4de9-a
as an example, but as I already said,
I don't like this approach very much.
--
Regards,
Alena Rybakina
Postgres Professional
rent->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
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
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 simple. If I'm
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
t 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
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
, 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 SubPlans
dd 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
ot, joinrel, outerpath, matpath,
pathkeys, jointype, extra);
--
Regards,
Alena Rybakina
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/subselect.out
index
yself
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 changes. After we reach to some agreement
on the above discussion, I think v4 is
<= 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 "=".
I took the liberty
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/optimizer/p
d/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
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 obvious example
ater.
I am also testing some experience with multi-column indexes using SAOPs.
--
Regards,
Alena Rybakina
Postgres Professional
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 what stage it is clear tha
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 to hear it, I've
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,
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
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 cc229d4dcaf..60e053d2179 100644
--- a/src/tes
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
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
6..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.239 ms
Execution Time: 70.860 ms
(10 rows)
--
Regards,
Alena Rybakina
Post
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
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 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 spaces.
I
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 Rybakina
Postgres Professional
From 54a24390f1137a77c9755a875774a75ae8cf2424 Mon Sep 17 00:00:00 2001
From: Toma
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 possible
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 f9f5958707bc1d7931323df05d51a60
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 answer you right away, I was too
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 read:
https
ot;unrecognized boolop: %d", (int) expr->boolop);
opname = NULL; /* keep compiler quiet */
break;
}
if (!or_statement || list_length(expr->args) < const_transform_or_limit)
return transformBoolExpr(pstate, (BoolExpr *)expr_orig);
The current version of the patch al
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/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c
index ef475d95a18..31771
caused by an incorrect calculation of selectivity in the "IS NULL" clause,
since it took into account only table-level statistics without zero values in
the results of the join operation. This patch fixes this by calculating the
fraction of zero values on the right side of the join witho
t;. I 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 I chang
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 the optimiser wh
e 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
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
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
were skipped due to data type incompatibility
COPY 1
postgres=# select * from t;
id | b
+
5 | \x
(1 row)
--
---
Alena Rybakina
Postgres Professional
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
and no functions
in explain.h have comments in it.
Regards,
--
Alena Rybakina
Postgres Professional
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
93 matches
Mail list logo
