es much more complicated and error-prone.
There are still many low-hanging fruit to be had that can improve
performance.
And the code can gradually and safely remove multithreading barriers.
1. gradual reduction of global variables
2. introduction of local context structures
3. shrink current structures (to fit in 32, 64 boundaries)
4. scope reduction
My 2c.
regards,
Ranier Vilela
Em seg., 5 de jun. de 2023 às 08:06, Ranier Vilela
escreveu:
> Em dom., 4 de jun. de 2023 às 23:37, Richard Guo
> escreveu:
>
>>
>> On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote:
>>
>>> Hi,
>>>
>>> Per Coverity.
>>>
Em dom., 4 de jun. de 2023 às 23:37, Richard Guo
escreveu:
>
> On Sun, Jun 4, 2023 at 8:42 PM Ranier Vilela wrote:
>
>> Hi,
>>
>> Per Coverity.
>>
>> At function ExtendBufferedRelShared, has a always true test.
>> eb.rel was dereferenced one li
s one less branch.
regards,
Ranier Vilela
avoid-unncessary-always-test-true.patch
Description: Binary data
;12|1|0|
;13|1|0|
;14|1|0|
;15|1|0|
;16|1|0|
;17|1|0|
etc, etc
regards,
Ranier Vilela
>
> Best regards,
> Alexander
>
Em sáb., 3 de jun. de 2023 às 09:00, Alexander Lakhin
escreveu:
> Hello Ranier,
>
> 03.06.2023 13:14, Ranier Vilela wrote:
> > Hi,
> >
> > This is for Postgres 17 (head).
> >
> > Per Coverity.
> > At function print_unaligned_text, variable "nee
Hi,
This is for Postgres 17 (head).
Per Coverity.
At function print_unaligned_text, variable "need_recordsep", is
unnecessarily set to true and false.
Attached a trivial fix patch.
regards,
Ranier Vilela
avoid-unused-value-print.patch
Description: Binary data
y one that looks like it could have a performance
> advantage is list_copy_move_nth_to_head() (which is the weirdest of the
> lot). I'm inclined not to have any of these single-use functions unless
> a performance case can be made for them.
>
I think you missed list_nth_xid, It makes perfect sense to exist.
regards,
Ranier Vilela
Em sex, 21 de abr de 2023 9:10 AM, David Rowley
escreveu:
> On Fri, 21 Apr 2023 at 23:16, Ranier Vilela wrote:
> > Perhaps list_delete_nth_cell needs to check NIL too?
> > + if (list == NIL)
> > + return NIL;
>
> Which cell would you be deleting from
(const List *list, void *datum)
list param pointer can be const here not?
regards,
Ranier Vilela
delete needs a careful review.
>I wonder if we can invent function list_nth_xid to do it, to keep
>consistent with list_nth/list_nth_int/list_nth_oid.
Perhaps list_nth_xid(const List *list, int n)?
regards,
Ranier Vilela
0001-add-new-list-functions.patch
Description: Binary data
Em qua., 12 de abr. de 2023 às 22:29, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> Perhaps it's a good idea to seprate the patch for each issue.
>
> Thanks Kyotaro for taking a look.
> At Wed, 12 Apr 2023 09:36:14 -0300, Ranier Vilela
> wrote in> IM
ce.
Taking advantage of this, I promoted a scope reduction for some variables,
which I thought was opportune.
Patch attached.
regards,
Ranier Vilela
001-fix-bufmgr-extend-variable-index.patch
Description: Binary data
Em sex., 31 de mar. de 2023 às 16:25, Tom Lane escreveu:
> Ranier Vilela writes:
> > I think that commit f0d65c0
> > <
> https://github.com/postgres/postgres/commit/f0d65c0eaf05d6acd3ae05cde4a31465eb3992b2
> >
> > has an oversight.
> > Attnum == 0, is sys
Hi,
I think that commit f0d65c0
<https://github.com/postgres/postgres/commit/f0d65c0eaf05d6acd3ae05cde4a31465eb3992b2>
has an oversight.
Attnum == 0, is system column too, right?
All other places at tablecmds.c, has this test:
if (attnum <= 0)
ereport(ERROR,
regards,
Rani
Em qua., 22 de mar. de 2023 às 07:01, Daniel Gustafsson
escreveu:
> > On 19 Mar 2023, at 23:41, Michael Paquier wrote:
> >
> > On Fri, Mar 17, 2023 at 12:19:56PM -0300, Ranier Vilela wrote:
> >> Rebased to latest Head.
> >
> > I was looking at this th
[2].
>
Rebased to latest Head.
best regards,
Ranier Vilela
v2-use-heapalloc-instead-deprecated-localalloc.patch
Description: Binary data
Em ter., 24 de jan. de 2023 às 07:24, Dean Rasheed
escreveu:
> On Tue, 24 Jan 2023 at 00:47, Ranier Vilela wrote:
> >
> > On 13.01.23 11:01, Dean Rasheed wrote:
> > > So I'm feeling quite good about the end result -- I set out hoping not
> > > to make perf
he "value" var is not leaked?
If not, sorry for the noise.
regards,
Ranier Vilela
avoid_leak_value_numeric.patch
Description: Binary data
" as well.
> >
> > The attached is what I mean. I'll commit this this week unless there are
> objections.
>
> I've pushed this and the cosmetic fix in pg_dump. Those were the only
> things I saw that had some interest, so I closed the CF entry.
>
Thanks for the commits.
regards,
Ranier Vilela
> Another thing that caught my attention is the assumption that unsetting a
> bit is so expensive that we have to first check if it's set, so we may as
> well remove "IS_BRACKET(Np->Num)" as well.
>
> The attached is what I mean. I'll commit this this week unless there are
> objections.
>
+1 looks good to me.
regards,
Ranier Vilela
there is no need to set NULL on
COPY_STRING_FIELD.
Regarding COPY_POINTER_FIELD, it is wasteful to cast size_t to size_t.
v3 attached.
regards,
Ranier Vilela
> regards, tom lane
>
>
v3-optimize_gen_node_support.patch
Description: Binary data
Em seg., 26 de dez. de 2022 às 15:45, Nikita Malakhov
escreveu:
> Hi,
>
> My bad, I was misleaded by unconditional return in ereturn_domain.
> Sorry for the noise.
>
By no means, the mistake was entirely mine, I apologize to you.
regards,
Ranier Vilela
Em sex., 23 de dez. de 2022 às 09:10, David Rowley
escreveu:
>
> I've now pushed your fix plus that test.
>
Thank you all for getting involved to resolve this.
regards,
Ranier Vilela
ed by caller?
>
I agreed that it is better to keep old behavior.
Even the value 0 is problematic, with calls like this:
nel = ARRNELEMS(ent);
memcpy(ptr, ARRPTR(ent), nel * sizeof(int32));
regards,
Ranier Vilela
Em ter., 20 de dez. de 2022 às 21:51, Justin Pryzby
escreveu:
> On Fri, Nov 25, 2022 at 06:27:04PM -0300, Ranier Vilela wrote:
> > 5. Use boolean operator with boolean operands
> > (b/src/backend/commands/tablecmds.c)
>
> tablecmds.c: right. Since 074c5cfbf
>
&g
ARRPTR(ent), nel * sizeof(int32));
}
Sources possibly affecteds:
contrib\cube\cube.c
contrib\intarray\_intbig_gist.c
contrib\intarray\_int_bool.c
contrib\intarray\_int_gin.c
contrib\intarray\_int_gist.c
contrib\intarray\_int_op.c
contrib\intarray\_int_tool.c:
Thoughts?
regards,
Ranier Vilela
Em qua., 21 de dez. de 2022 às 04:10, Michael Paquier
escreveu:
> On Tue, Dec 20, 2022 at 06:51:34PM -0600, Justin Pryzby wrote:
> > On Fri, Nov 25, 2022 at 06:27:04PM -0300, Ranier Vilela wrote:
> > > 5. Use boolean operator with boolean operands
> > > (b/src/b
Thanks David, for looking at this.
Em ter., 20 de dez. de 2022 às 22:45, David Rowley
escreveu:
> On Wed, 21 Dec 2022 at 13:15, Ranier Vilela wrote:
> > IMO, I think that commit a61b1f7, has an oversight.
> > Currently is losing the result of recurs
Thanks for looking at this.
Em ter., 20 de dez. de 2022 às 21:51, Justin Pryzby
escreveu:
> On Fri, Nov 25, 2022 at 06:27:04PM -0300, Ranier Vilela wrote:
> > 5. Use boolean operator with boolean operands
> > (b/src/backend/commands/tablecmds.c)
>
> tablecmds.c: ri
signed.
Without a test case for this patch.
But also, do not have a test case for the current thinko in head.
Pass regress check.
regards,
Ranier Vilela
avoid_lost_result_of_recursion.patch
Description: Binary data
scope of vars:
RangeTblEntry *rte
Oid userid;
+ if (varno != relid)
+ {
+ RangeTblEntry *rte;
+ Oid userid;
0005:
+1
0006:
+1
regards,
Ranier Vilela
Hi, thanks for reviewing this.
Em sex., 2 de dez. de 2022 às 09:24, John Naylor <
john.nay...@enterprisedb.com> escreveu:
>
> On Thu, Dec 1, 2022 at 8:02 PM Ranier Vilela wrote:
> >
> > Hi,
> >
> > I believe that has room for improving generation node files
noring the result of pg_strtok when it is
unnecessary.
regards,
Ranier Vilela
optimize_gen_nodes_support.patch
Description: Binary data
r do you want
> to
> > check the original patch again for context?
>
> Most of the changes of this thread have been applied as of c42cd05c.
> Remains the SIGALRM business with sig_atomic_t, and I wanted to check
> that by myself first.
>
Thank you Michael, for taking care of it.
regards,
Ranier Vilela
+', is different than "!= '-'" and is different than "!= '+'"
So the else is never hit.
Per Coverity.
5. Use boolean operator with boolean operands
(b/src/backend/commands/tablecmds.c)
regards,
Ranier Vilela
avoid_useless_pointer_increment.patch
Descript
Em qua., 16 de nov. de 2022 às 03:59, Michael Paquier
escreveu:
> On Tue, Oct 04, 2022 at 08:23:16AM -0300, Ranier Vilela wrote:
> > Both are correct, I missed the pqsignal calls.
> >
> > Attached patch to change this.
>
> The change for pgbench is missin
> I have spotted more optimizations possible, particularly for operator
> classes, but that could happen later.
>
Good to know.
regards,
Ranier Vilela
elements to insert.
>
Makes sense.
>
> So I've given a try at all that, and finished with the attached. This
> patch finishes with a list of bullet points, so this had better be
> split into different commits, I guess.
> Thoughts?
>
Missed AddRoleMems?
Could you continue with CatalogTupleInsertWithInfo, what do you think?
regards,
Ranier Vilela
Em sex., 11 de nov. de 2022 às 01:54, Michael Paquier
escreveu:
> On Thu, Nov 10, 2022 at 08:56:25AM -0300, Ranier Vilela wrote:
> > For CopyStatistics() have performance checks.
>
> You are not giving all the details of your tests, though,
Windows 10 64 bits
SSD 256
Em qui., 10 de nov. de 2022 às 05:16, Michael Paquier
escreveu:
> On Thu, Sep 01, 2022 at 08:42:15AM -0300, Ranier Vilela wrote:
> > Let's wait for the patch to be accepted and committed, so we can try to
> > change it.
>
> FWIW, I think that this switch is a go
Em sex., 7 de out. de 2022 às 15:45, Ranier Vilela
escreveu:
> Em sex., 7 de out. de 2022 às 14:44, Tom Lane
> escreveu:
>
>> Ranier Vilela writes:
>> > Anyway, it's not *true* that collectMatchesForHeapRow deals
>> > only "true" and &quo
Em sex., 7 de out. de 2022 às 14:44, Tom Lane escreveu:
> Ranier Vilela writes:
> > Anyway, it's not *true* that collectMatchesForHeapRow deals
> > only "true" and "false", once that key->entryRes is initialized with
> > GIN_FALSE not false.
&
v9-001-improve-scability.patch
27/06/2020 11:17 7.754 windows_fixes_v1.patch
And it could contribute much, much more.
regards,
Ranier Vilela
Em sex., 7 de out. de 2022 às 12:40, Tom Lane escreveu:
> Robert Haas writes:
> > On Thu, Oct 6, 2022 at 8:35 PM Ranier Vilela
> wrote:
> >> No Tom, unfortunately I don't have the knowledge to create a test with
> GIN_MAYBE values.
>
> > Well then don'
Em qui., 6 de out. de 2022 às 21:21, Tom Lane escreveu:
> Ranier Vilela writes:
> > My main concerns is this point:
> > /* If already matched on earlier page, do no extra work */
> > - if (key->entryRes[j])
> > + if (key->entryRes[j] == GIN_TRUE)
> >
Em qui., 6 de out. de 2022 às 20:52, Tom Lane escreveu:
> Ranier Vilela writes:
> > So, any use of this GinTernaryValue are:
>
> > 1. if (key->entryRes[j]) be FALSE if GIN_FALSE
> > 2. if (key->entryRes[j]) be TRUE if GIN_TRUE
> > 3. if (key->entryRes[j]
se of this GinTernaryValue are:
1. if (key->entryRes[j]) be FALSE if GIN_FALSE
2. if (key->entryRes[j]) be TRUE if GIN_TRUE
3. if (key->entryRes[j]) be TRUE if GIN_MAYBE
So gin matchs can fail with GYN_MAYBE or I lost something?
regards,
Ranier Vilela
avoid_mix_bool_with_char_comparator.patch
Hi,
Like how commits series "harmonize parameter names":
20e69da
<https://github.com/postgres/postgres/commit/20e69daa1348f6899fffe3c260bf44293551ee87>
and others.
This tries to harmonize more parameter names, mainly in Win32 and
some others files.
regard
Em qua., 5 de out. de 2022 às 09:19, Ranier Vilela
escreveu:
> Hi,
> I think that 9d58bf
> <https://github.com/postgres/postgres/commit/a9d58bfe8a3ae2254e1553ab76974feeaafa0133>,
> left a tiny oversight.
>
> guc_strdup uses strdup, so must be cleaned by free not pfree.
Hi,
I think that 9d58bf
<https://github.com/postgres/postgres/commit/a9d58bfe8a3ae2254e1553ab76974feeaafa0133>,
left a tiny oversight.
guc_strdup uses strdup, so must be cleaned by free not pfree.
IMO, can be used once free call too.
regards,
Ranier
Em ter., 4 de out. de 2022 às 08:29, Ranier Vilela
escreveu:
> Em ter., 4 de out. de 2022 às 05:36, David Rowley
> escreveu:
>
>> On Tue, 4 Oct 2022 at 13:35, Ranier Vilela wrote:
>> > Revisiting my work on reducing memory consumption, I found this patch
>> lef
Em ter., 4 de out. de 2022 às 05:36, David Rowley
escreveu:
> On Tue, 4 Oct 2022 at 13:35, Ranier Vilela wrote:
> > Revisiting my work on reducing memory consumption, I found this patch
> left out.
> > I'm not sure I can help.
> > But basically I was able to writ
Em ter., 4 de out. de 2022 às 01:18, Michael Paquier
escreveu:
> On Mon, Oct 03, 2022 at 08:05:57AM -0300, Ranier Vilela wrote:
> > Em seg., 3 de out. de 2022 às 05:01, Masahiko Sawada <
> sawada.m...@gmail.com>
> > escreveu:
> >> On Fri, Sep 30, 2022 at 9:08 A
regards,
Ranier Vilela
001-reduces-memory-consumption.patch
Description: Binary data
Em seg., 3 de out. de 2022 às 09:40, Julien Rouhaud
escreveu:
> On Mon, Oct 03, 2022 at 09:05:34AM -0300, Ranier Vilela wrote:
> > >Please let us know if you have any questions. We're excited that we are
> > >very close to officially releasing PostgreSQL 15.
&g
Em seg., 3 de out. de 2022 às 09:39, Justin Pryzby
escreveu:
> On Mon, Oct 03, 2022 at 09:05:34AM -0300, Ranier Vilela wrote:
> > >Please let us know if you have any questions. We're excited that we are
> > >very close to officially releasing PostgreSQL 15.
> > Hi
2a22
<https://github.com/postgres/postgres/commit/8cb2a22bbb2cf4212482ac15021ceaa2e9c52209>
(bug fix), not included?
I think users of this function should be better informed.
regards,
Ranier Vilela
Em seg., 3 de out. de 2022 às 05:01, Masahiko Sawada
escreveu:
> On Fri, Sep 30, 2022 at 9:08 AM Ranier Vilela wrote:
> >
> > Hi.
> >
> > There are assorted fixes to the head branch.
> >
> > 1. Avoid useless reassigning var _logsegno
> (src/backend/acce
ackend/utils/misc/guc.c)
The var record is never really used.
4. Fix declaration volatile signal var (src/bin/pgbench/pgbench.c)
Like how to commit 5ac9e86
<https://github.com/postgres/postgres/commit/5ac9e869191148741539e626b84ba7e77dc71670>,
this is a similar case.
regards,
R
l see the memory usage increase and
> get the OOMs
>
Thanks for sharing the result.
regards,
Ranier Vilela
query like the following:
>```
>explain SELECT count(*) FROM t1 JOIN t2 USING (a);
I run your test here with a fix attached.
Can you retake your test with the patch attached?
regards,
Ranier Vilela
fix_possible_memory_leak_merge_join_sort.patch
Description: Binary data
Em qui., 15 de set. de 2022 às 10:30, Daniel Gustafsson
escreveu:
> > On 15 Sep 2022, at 15:13, Alvaro Herrera
> wrote:
> >
> > On 2022-Sep-15, Ranier Vilela wrote:
> >
> >> Em qui., 15 de set. de 2022 às 09:50, Alvaro Herrera <
> >> alvhe...@alv
Em qui., 15 de set. de 2022 às 10:13, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Sep-15, Ranier Vilela wrote:
>
> > Em qui., 15 de set. de 2022 às 09:50, Alvaro Herrera <
> > alvhe...@alvh.no-ip.org> escreveu:
>
> > > These functio
Em qui., 15 de set. de 2022 às 09:50, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Sep-14, Ranier Vilela wrote:
>
> > According to:
> >
> https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-localalloc
>
> > LocalAlloc is depr
message and had some issues with
> the formating. I fixed this. The new code checks the return value of
> GetProcessHeap() which is unlikely to fail, so I figured unlikely() is
> appropriate:
>
> + hDefaultProcessHeap = GetProcessHeap();
> + if (unlikely(hDefaultProcessHeap == NULL))
>
> The corrected patch is attached.
>
Thanks for the review and fixes.
regards,
Ranier Vilela
Em qui., 15 de set. de 2022 às 05:35, Daniel Gustafsson
escreveu:
> > On 15 Sep 2022, at 01:19, Ranier Vilela wrote:
>
> > LocalAlloc is deprecated.
> > So use HeapAlloc instead, once LocalAlloc is an overhead wrapper to
> HeapAlloc.
> >
> > Attached a patch.
hat a local function should be
used. For more information, see Global and Local Functions."
LocalAlloc is deprecated.
So use HeapAlloc instead, once LocalAlloc is an overhead wrapper to
HeapAlloc.
Attached a patch.
regards,
Ranier Vilela
use-heapalloc-instead-deprecated-localalloc.patch
D
Em seg., 5 de set. de 2022 às 23:02, David Rowley
escreveu:
> On Tue, 6 Sept 2022 at 13:52, Ranier Vilela wrote:
> >
> > Em seg., 5 de set. de 2022 às 22:29, David Rowley
> escreveu:
> >> It feels like it would be good if we had a way to detect a few of
> >&g
Em ter., 13 de set. de 2022 às 11:09, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2022-Sep-13, Ranier Vilela wrote:
>
> > However, for Postgres 15 this may can cause a small memory leak.
>
> What memory leak? There's no leak here.
>
Yeah, as per Jul
fix patch.
regards,
Ranier Vilela
avoid-redundant-initialization-and-possible-memory-leak.patch
Description: Binary data
pushed this.
>
Thank you David.
But the correct thing is to put you also as author, after all, there's more
of your code there than mine.
Anyway, I appreciate the consideration.
regards,
Ranier Vilela
Thank you for the commit.
regards,
Ranier Vilela
Created a CF entry.
https://commitfest.postgresql.org/40/3883/
Attached a patch with a fix correction to regress output.
I think this needs to be backpatched until version 12.
regards,
Ranier Vilela
v1-0001-fix-typo-isnan-test-geo_ops.patch
Description: Binary data
Em sex., 9 de set. de 2022 às 18:53, Tom Lane escreveu:
> Ranier Vilela writes:
> > Em sex., 9 de set. de 2022 às 13:20, Nathan Bossart <
> > nathandboss...@gmail.com> escreveu:
> >> I agree with David [0]. But if you can demonstrate a performance gain,
> &g
Em sex., 9 de set. de 2022 às 10:45, Ranier Vilela
escreveu:
> Based on work in [1].
> According to https://cplusplus.com/reference/cstdio/fprintf/
> The use of fprintf is related to the need to generate a string based on a
> format, which should be different from "%s"
Em sex., 9 de set. de 2022 às 13:20, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Fri, Sep 09, 2022 at 10:45:37AM -0300, Ranier Vilela wrote:
> > Based on work in [1].
> > According to https://cplusplus.com/reference/cstdio/fprintf/
> > The use of fprint
.c).
Patch attached.
This pass check-world.
regards,
Ranier Vilela
[1]
https://www.postgresql.org/message-id/CAApHDvp2THseLvCc%2BTcYFBC7FKHpHTs1JyYmd2JghtOVhb5WGA%40mail.gmail.com
[2]
https://stackoverflow.com/questions/20837989/fprintf-stack-buffer-overflow
[3]
https://bufferoverflows.net/format-
Em seg., 5 de set. de 2022 às 23:02, David Rowley
escreveu:
> On Tue, 6 Sept 2022 at 13:52, Ranier Vilela wrote:
> >
> > Em seg., 5 de set. de 2022 às 22:29, David Rowley
> escreveu:
> >> It feels like it would be good if we had a way to detect a few of
> >&g
Em seg., 5 de set. de 2022 às 22:29, David Rowley
escreveu:
> On Tue, 6 Sept 2022 at 06:07, Ranier Vilela wrote:
> > I did a search and found a few more places.
> > v1 attached.
>
> Thanks. I've done a bit more looking and found a few more places that
> we ca
Em seg., 5 de set. de 2022 às 10:40, David Rowley
escreveu:
> On Mon, 5 Sept 2022 at 22:15, David Rowley wrote:
> > On Sat, 3 Sept 2022 at 00:37, Ranier Vilela wrote:
> > > 6. Avoid overhead when using unnecessary StringInfoData to convert
> Datum a to Text b.
> >
&g
Em seg., 5 de set. de 2022 às 07:15, David Rowley
escreveu:
> On Sat, 3 Sept 2022 at 00:37, Ranier Vilela wrote:
> >> But +1 to fix this and other issues even if they would never crash.
>
> Yeah, I don't think any of this coding would lead to a crash, but it's
Em dom., 4 de set. de 2022 às 09:58, Ranier Vilela
escreveu:
>
> Now I have some trouble in c.h with one my tools:
> Windows 10 64 bits
> msvc 2019 64 bits
> #error must have a working 64-bit integer datatype
>
Nevermind , found the cause.
regards,
Ranier Vilela
2019 64 bits
#error must have a working 64-bit integer datatype
Strange.
regards,
Ranier Vilela
| <(3,5),NaN>
-(9 rows)
+(8 rows)
-- Overlap with circle
SELECT c1.f1, c2.f1 FROM CIRCLE_TBL c1, CIRCLE_TBL c2 WHERE c1.f1 && c2.f1;
Not sure why.
regards,
Ranier Vilela
Em sex., 2 de set. de 2022 às 16:15, Daniel Gustafsson
escreveu:
> > On 2 Sep 2022, at 21:08, Ranier Vilela wrote:
>
> > At function circle_same the second isnan test is wrong.
>
> Yeah, that seems pretty wrong. Did you attempt to procure a test for when
> this
> yi
Hi,
I think that this is a typo.
At function circle_same the second isnan test is wrong.
Attached fix patch.
regards,
Ranier Vilela
0001-fix-typo-isnan-test-geo_ops.patch
Description: Binary data
Em sex., 2 de set. de 2022 às 09:01, Justin Pryzby
escreveu:
> On Mon, Aug 29, 2022 at 10:06:55AM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 26 Aug 2022 10:28:50 -0300, Ranier Vilela
> wrote in
> > > At function has_matching_range, if variable ranges->nranges == 0,
>
Em qui., 1 de set. de 2022 às 21:27, David Rowley
escreveu:
> On Sat, 27 Aug 2022 at 01:29, Ranier Vilela wrote:
> > At function has_matching_range, if variable ranges->nranges == 0,
> > we exit quickly with a result equal to false.
> >
> > This means that nran
tValue(chunk);
AllocBlock block = MemoryChunkGetBlock(chunk);
AllocFreeListLink *link = GetFreeListLink(chunk);
MemoryChunkGetValue return Size not int.
Not sure if this fix is enough.
regards,
Ranier Vilela
Em qua., 31 de ago. de 2022 às 22:12, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Wed, 31 Aug 2022 08:16:55 -0300, Ranier Vilela
> wrote in
> > Hi,
> >
> > The commit
> >
> https://github.com/postgres/postgres/commit/b17ff07aa3eb142d2cde
1. REINDEX TABLE CONCURRENTLY pgbench_accounts;
Time: 65,048 ms
Time: 61,853 ms
Time: 61,119 ms
2. REINDEX TABLE CONCURRENTLY pgbench_tellers;
Time: 15,999 ms
Time: 15,961 ms
Time: 13,264 ms
There are other places that this could be useful,
but a careful analysis is necessary.
regards,
Ranier V
ed USING hash (x);
head:
Time: 20526,490 ms (00:20,526)
attached patch (v3):
Time: 18810,777 ms (00:18,811)
I can see 9%, with the patch (v3) attached.
This optimization would not apply in any way also to _hash_pgaddmultitup?
regards,
Ranier Vilela
diff --git a/src/backend/access/hash/hash.c
Em dom., 28 de ago. de 2022 às 22:06, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Fri, 26 Aug 2022 10:28:50 -0300, Ranier Vilela
> wrote in
> > At function has_matching_range, if variable ranges->nranges == 0,
> > we exit quickly with a result equal t
Em sáb., 27 de ago. de 2022 às 00:00, Michael Paquier
escreveu:
> On Fri, Aug 26, 2022 at 01:54:26PM -0300, Ranier Vilela wrote:
> > Is it worth creating a commiffest?
>
> Don't think so, but feel free to create one and mark me as committer
> if you think that's appr
invalid socket, is correct, so as we always have our hands
> on a way to cancel a command.
>
Thanks Michael, for looking at this.
Is it worth creating a commiffest?
regards,
Ranier Vilela
ual to zero, there is no need to initialize minvalue and
maxvalue.
The patch tries to fix it, avoiding possible errors by using maxvalue.
regards,
Ranier Vilela
0001-fix-bogus-possible-array-out-bonds.patch
Description: Binary data
Em qui., 25 de ago. de 2022 às 14:31, Ranier Vilela
escreveu:
> >The postgres_fdw tests contain this (as amended by patch 0001):
>
> >ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
> >ERROR: invalid option "password"
> >HINT: Valid
t;- Hide the hint from this particular test (done in the attached patches).
+1
I vote for this option.
Less work for future developers changes, I think worth the effort.
Anyway, in alphabetical order, it's a lot easier for users to read.
Patch attached.
regards,
Ranier Vilela
0003-reorder-alphabetical-libpq-options.patch
Description: Binary data
Em qua., 24 de ago. de 2022 às 16:41, Robert Haas
escreveu:
> On Wed, Aug 24, 2022 at 3:20 PM Ranier Vilela wrote:
> > But, these same arguments apply to Designated Initializers [1].
> >
> > like:
> > struct foo a = {
> >.i = 0,
> >.b = 0,
> &g
201 - 300 of 881 matches
Mail list logo
