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 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
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
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
; 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 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,
>>
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
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
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
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.
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!
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!
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!
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
changed), but the idea of fixing the error looks good to me.
Best Regards, Stepan Neretin!
Hi, looks good for me, but please fix formatting in temp_tbl_fix.patch!
e issue manually before your changes, but I am
unable to do so in the perl test.
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!
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.
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!
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.
e the documentation.
Best regards, Stepan Neretin.
bench)
What do you think is the format in which to make benchmarks for my patches?
Best regards, Stepan Neretin.
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
> 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
-copy-freeze/
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
value of these functions is checked, and in some not? Can I add
checks everywhere?
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
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.
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
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 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
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
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.
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
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.
; 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.
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.
Hi! Looks good to me!
Best regards, Stepan Neretin.
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.
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
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
46 matches
Mail list logo
