Time taken by list_sort: 118168506 ns, Time taken by list_int_sort:
80523373 ns, Percentage difference: 31.86%
(1 row)
What do you think about these changes?
Best regards, Stepan Neretin.
On Fri, Jun 7, 2024 at 11:08 PM Andrey M. Borodin
wrote:
> Hi!
>
> In a thread abou
On Sat, Jun 8, 2024 at 1:50 AM Stepan Neretin wrote:
> Hello all.
>
> I am interested in the proposed patch and would like to propose some
> additional changes that would complement it. My changes would introduce
> similar optimizations when working with a list of int
It looks useful, for example, it can be used in sorting tests to make them more
interesting. I just have one question. Why are you using SRF_IS_FIRST CALL and
not _PG_init?
Best regards, Stepan Neretin.
Hi! Looks good to me!
Best regards, Stepan Neretin.
ge difference in behavior in these two queries,
it seems to me that although it returns a string by default, for the boolean
operator it is necessary to return true or false
SELECT * FROM JSON_value (jsonb '1', '$ == "1"' returning jsonb);
json_value
--------
(1 row)
SELECT * FROM JSON_value (jsonb 'null', '$ == "1"' returning jsonb);
json_value
false
(1 row)
Best regards, Stepan Neretin.
; get at the Windows-style *_s() functions by supplying some additional
> options or defines. But we might as well just use the POSIX ones.)
>
>
Hi! Looks good to me.
But why you don`t change localtime function at all places?
For example:
src/bin/pg_controldata/pg_controldata.c
src/bin/pg_dump/pg_backup_archiver.c
src/bin/initdb/findtimezone.c
Best regards, Stepan Neretin.
ror-raising query that passes the silent arg, which would also suppress
> the error.
>
> Added a variant where the silent param suppresses the error, too.
>
> V2 attached and the PR updated:
>
> https://github.com/theory/postgres/pull/4/files
>
> Best,
>
> David
>
>
>
>
HI! Now it looks good for me.
Best regards, Stepan Neretin.
Hi! Looks good to me. Please, register it in CF.
Best regards, Stepan Neretin.
On Fri, Jun 28, 2024 at 10:05 AM Junwang Zhao wrote:
> fastgetattr and heap_getattr are converted to inline functions
> in e27f4ee0a701, while some comments still referring them as macros.
>
> --
> Re
might need further discussion.
>
> Regards,
> Dean
>
Hi! The patch file seems broken.
git apply gamma-and-lgamma.patch
error: git apply: bad git-diff — exptec /dev/null in line 2
Best regards, Stepan Neretin.
On Mon, Jul 1, 2024 at 5:33 PM Dean Rasheed
wrote:
> Attached is a patch adding support for the gamma and log-gamma
> functions. See, for example:
>
> https://en.wikipedia.org/wiki/Gamma_function
>
> I think these are very useful general-purpose mathematical functions.
> They're part of C99, and
On Mon, Jul 15, 2024 at 12:44 PM Антуан Виолин
wrote:
> On 2024-04-03 Wn 04:21, Andrew Dunstan
>
>> I don't think a cast that doesn't cater for all the forms json can take
>> is going to work very well. At the very least you would need to error out
>> in cases you didn't want to cover, and have t
t;worst case" test, sorting the array in ascending order when it
> is initially descending
>
> Best, regards, Antoine Violin
>
> postgres=#
>>
>
> On Mon, Jul 15, 2024 at 10:32 AM Stepan Neretin wrote:
>
>>
>>
>> On Sat, Jun 8, 2024 at
On Mon, Jul 15, 2024 at 4:52 PM Stepan Neretin wrote:
>
>
> On Mon, Jul 15, 2024 at 12:23 PM Антуан Виолин
> wrote:
>
>> Hello all.
>>>
>>> I have decided to explore more areas in which I can optimize and have
>>> added
>>> two new bench
ions be grouped closer to the existing tests rather than added at
> > the end of the file?
>
> I’ve moved them closer to other tests for unwrapping behavior in the
> attached updated and rebased v3 patch.
>
> Best,
>
> David
>
>
>
Hi! Looks good to me now! Please, register a patch in CF.
Best regards, Stepan Neretin.
-copy-freeze/
Best regards, Stepan Neretin.
> So if we tell extension authors they don't need to check the result, it's
unlikely
> that that will cause any new code they write to get used with PG
> versions where it would be wrong.
Yes, I concur.
> This combines portions of Stepan's
> two patches with some additional work (mostly, that he'd
Hi! I rebase, clean and some refactor my patches.
Best regards, Stepan Neretin.
From f88cbb80e478d5ac3f23945b4ba0ee881f0d9cd4 Mon Sep 17 00:00:00 2001
From: "Andrey M. Borodin"
Date: Sun, 8 Sep 2024 15:43:39 +0700
Subject: [PATCH v2 01/10] Use specialized sort facilities
---
contri
bench)
What do you think is the format in which to make benchmarks for my patches?
Best regards, Stepan Neretin.
On Tue, Jul 16, 2024 at 1:47 AM Andrey M. Borodin
wrote:
>
>
> > On 15 Jul 2024, at 12:52, Stepan Neretin wrote:
> >
> >
> > I run benchmark with my patches:
> > ./pgbench -c 10 -j2 -t1000 -d postgres
> >
> > pgbench (18devel)
> > starting v
value of these functions is checked, and in some not? Can I add
checks everywhere?
Best Regards, Stepan Neretin.
ks everywhere (at least in the
documentation).
What do you think about the attached patch?
Best Regards, Stepan Neretin.
From 4c8d6d9ae6f8843bc6d1ad203d629df09657b039 Mon Sep 17 00:00:00 2001
From: Stepan Neretin
Date: Sat, 10 Aug 2024 21:30:37 +0300
Subject: [PATCH v1] Fix SPI Documentation - Sta
e the documentation.
Best regards, Stepan Neretin.
Hi there! It looks good to me! But I have a question. How is the
partialxlogfname freed in case of an error?
Best regards, Stepan Neretin.
Hi, looks good for me, but please fix formatting in temp_tbl_fix.patch!
Hello Aleksander! I'm a beginner and I would like to see and try your
patch. However, I have never worked with coverage in regression tests for
PostgreSQL. Could you please tell me how it works and help me understand
the process? Thanks!
Best Regards, Stepan Neretin!
Dear Nazir,
At first A quick look it looks good. I will take a closer look at it
tomorrow. Could you please let me know about the performance tests and
graphics?
Best regards, Stepan Neretin!
n reasonable bounds and that the calculated timestamp is accurate.
Examples of checks could include verifying if the interval is too small,
too large, or exceeds the maximum possible number of milliseconds and
nanoseconds in a timestamp.
By implementing these changes, we can improve the accuracy and reliability
of UUID generation, making it more suitable for high-frequency usage
scenarios.
What do you think about these suggestions? Let me know your thoughts!
Best Regards, Stepan Neretin!
int primary key);");
$node->stop('immediate');
sleep(5);
$node->start;
sleep(3);
$node->restart;
my $psql2 = $node->interactive_psql('postgres');
$psql2->query('SELECT 1;');
$psql2->query('SELECT 1;');
my $regexp = qr/autovacuum/;
my $offset = 0;
$node->wait_for_log($regexp, $offset);
done_testing();
```
Best Regards, Stepan Neretin.
ELECT injection_points_attach('autovacuum-worker-start',
'wait');");
$node->wait_for_event('autovacuum worker', 'autovacuum-worker-start');
$psql2->query('select 1');
my $regexp = qr/autovacuum:/;
my $offset = 0;
ok( $node->log_contains(
$regexp,
$offset),
"autovacuum not started");
done_testing();
```
Best Regards, Stepan Neretin!
e issue manually before your changes, but I am
unable to do so in the perl test.
Best Regards, Stepan Neretin!
teractive_psql('postgres');
$psql1->query("create temp table test (a int primary key);");
$node->stop('immediate');
$node->start();
sleep(5);
$node->restart();
ok(1);
done_testing();
```
Best Regards, Stepan Neretin!
changed), but the idea of fixing the error looks good to me.
Best Regards, Stepan Neretin!
Hi there, hackers! How about trying out an idea to add an analog to save
memory in WAL files for deleting records, similar to multi-insert
optimization? This patch is trying to do just that.
Best Regards, Stepan Neretin!
diff --git a/src/backend/executor/nodeModifyTable.c b/src/backend/executor
nimize the impact of AccessExclusive locks. This patch is a
step toward improving the situation.
The patch is attached to this message.
Best regards, Stepan Neretin.
diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c
index 159b822740ab32989d8e5d4da71a61
ssues with code style.
Thanks for the patch - it could indeed help prevent future issues.
Best regards,
Stepan Neretin
вт, 11 мар. 2025 г., 17:32 Daniil Davydov <3daniss...@gmail.com>:
> Hi,
> I am posting the new v2 patch, which is now rebased on the `master` branch.
> Waiti
it.
>
> With the best regards,
>
> --
> Anton A. Melnikov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
Hi, I reproduce the problem step by step. Patch fixes this problem. Looks
good to me.
Best Regards, Stepan Neretin.
On Sat, May 10, 2025 at 6:01 PM Stepan Neretin wrote:
>
>
> On Thu, May 8, 2025 at 6:57 AM Matthew Sterrett <
> matthewsterre...@gmail.com> wrote:
>
>> Hello! I'm still trying to figure out those CI failures, I just wanted
>> to update things.
>>
&g
where this
SQL-level workaround wouldn't be sufficient? Are there error types you
intend to handle that cannot be gracefully avoided or recovered from using
SQL constructs like ON CONFLICT, or SAVEPOINT/ROLLBACK TO?
Best regards,
Stepan Neretin
patch!
I ran some timing tests:
(without avx2)
Time: 4034.351 ms
SELECT drive_pg_checksum(512);
(with avx2)
Time: 3559.076 ms
SELECT drive_pg_checksum(512);
Also attached two patches that should fix the CI issues.
Best,
Stepan Neretin
s fail.
>
> +1. I've had similar cases before too, where I'd wanted pgbench to
> continue creating load on the server even if a transaction failed
> server-side for any reason. Sometimes, I'd even want that type of
> load.
>
> On Sat, 10 May 2025 at 17:02, Stepan
On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>
> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>
>>
>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>> > On Wed, 26 Mar 2025 at 12:17, Steven Niu wrote:
>> >>
>> >> Hi,
>>
; https://www.postgresql.org/message-id/flat/78574b24-be0a-42c5-8075-3fa9fa63b...@amazon.com
Hi, looks good for me.
Best regards,
Stepan Neretin.
.468231 ms
NOTICE: Average time per call: 0.463909 ms
The gain is small but consistent. Let me know if a more rigorous benchmark
would be useful.
Best regards,
Stepan Neretin
On Mon, Apr 14, 2025 at 1:10 PM Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Wed, Mar 26, 2025 at 2:14 PM Stepan Neretin wrote:
> >
> > The first thing we both noticed is that the macro calls a function that
> won't be available without an
On Fri, May 9, 2025 at 5:37 PM Stepan Neretin wrote:
>
>
> On Fri, May 9, 2025 at 5:24 PM Stepan Neretin wrote:
>
>>
>>
>> On Wed, Mar 26, 2025 at 9:39 PM Steven Niu wrote:
>>
>>>
>>> 在 2025/3/26 16:37, Kirill Reshke 写道:
>>> >
ize and again to fill in the bytea.
This patch eliminates the double scan by using a single-pass approach with
`StringInfo`, simplifying the logic and improving maintainability.
Changes since v1 (originally by Steven Niu):
- Use `StringInfo` instead of manual memory allocation.
- Remove redundant
On Mon, Jul 28, 2025 at 1:41 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sunday, July 27, 2025, Stepan Neretin wrote:
>>
>> One small thing: it seems the commit or diff with the final adjustments
>> and test additions wasn't attached or
ase
point me to the commit hash or reference? I’d love to take a look at the
final version.
Best regards,
*Stepan Neretin*
ior when trying to access
another backend's temp tables. It confirms the restrictions work as
intended while allowing permitted operations.
Thanks for working on this important security enhancement!
Best regards,
Stepan Neretin
From da27bc190faab3853f6a2cc0748f1f5476215001 Mo
PostgreSQL’s architecture and operational expectations?
Thanks,
Stepan Neretin
[1]
https://www.postgresql.org/message-id/flat/BC335D75-105B-403F-9473-976C8BBC32E3%40yandex-team.ru#d45caa9d1075734567164f73371baf00
From 08104dcdd3295a48827e1d58c4c2382620267f5d Mon Sep 17 00:00:00 2001
From: Stepan Neretin
PGRES_PIPELINE_SYNC
> >> is always followed by a NULL. However, it seems that another
> >> PGRES_PIPELINE_SYNC can appear consecutively, which violates that
> assumption
> >> and causes the assertion to fail. Thought?
> >
> > Yes. When an error occurs and an error response message returned from
> > backend, pgbench will send one more sync message, then sends ROLLBACK
> > if necessary. I think the code above should be changed to call
> > PQgetResult repeatably until it returns NULL.
>
> Correction. That would not be a proper fix. Just removing inner
> PQgetResult and the Assert is enough?
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>
>
Hi, Tatsuo.
Do you understand why there is an assertion error in the immediate shutdown
case?
Best Regards,
Stepan Neretin
51 matches
Mail list logo
