On Wed, Mar 29, 2023 at 8:34 PM Alexander Korotkov wrote:
> On Mon, Mar 27, 2023 at 1:49 PM Alexander Korotkov
> wrote:
> > On Fri, Mar 24, 2023 at 3:39 AM Andres Freund wrote:
> > > On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > > > On Thu, Mar
Andres,
On Mon, Mar 27, 2023 at 1:49 PM Alexander Korotkov wrote:
> On Fri, Mar 24, 2023 at 3:39 AM Andres Freund wrote:
> > On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > > On Thu, Mar 23, 2023 at 8:06 PM Andres Freund wrote:
> > > >
On Tue, Mar 28, 2023 at 9:44 PM Gregory Stark (as CFM)
wrote:
> On Wed, 31 Aug 2022 at 20:52, Alexander Korotkov wrote:
> >
> > I'll continue work on this patch. The rebased patch is attached. It
> > implements stop events as configure option (not runtime GUC optio
Hi!
On Fri, Mar 24, 2023 at 3:39 AM Andres Freund wrote:
> On 2023-03-23 23:24:19 +0300, Alexander Korotkov wrote:
> > On Thu, Mar 23, 2023 at 8:06 PM Andres Freund wrote:
> > > I seriously doubt that solving this at the tuple locking level is the
> > > right
>
Hi!
On Thu, Mar 23, 2023 at 3:30 AM Andres Freund wrote:
> On 2023-03-21 01:25:11 +0300, Alexander Korotkov wrote:
> > I'm going to push patchset v15 if no objections.
>
> Just saw that this went in - didn't catch up with the thread before,
> unfortunately. At the very least I'
et Dean
Rasheed is going to revise the locking for MERGE soon [1].
Pavel, could you please re-run your test case on the revised patch?
1.
https://www.postgresql.org/message-id/caezatcu9e9ccbi70ynbccf7xvz+zrjid0_6eeq2zeza1p+7...@mail.gmail.com
--
Regards,
Alexander Korotkov
From a06e0864fd45b3fca
for CMD_DELETE.
That ends up by usage of LockTupleNoKeyExclusive for CMD_DELETE, which
seems plain wrong for me.
The proposed change is attached.
--
Regards,
Alexander Korotkov
0001-ExecMergeMatched-lock-mode.patch
Description: Binary data
On Wed, Mar 8, 2023 at 4:22 AM Andres Freund wrote:
> On 2023-03-07 04:45:32 +0300, Alexander Korotkov wrote:
> > The second patch now implements a concept of LazyTupleTableSlot, a slot
> > which gets allocated only when needed. Also, there is more minor
> > refactor
On Tue, Mar 7, 2023 at 7:26 PM Pavel Borisov wrote:
> On Tue, 7 Mar 2023, 10:10 Alexander Korotkov, wrote:
>> I don't know what exactly Pavel meant, but average overall numbers for
>> low concurrency are.
>> master: 420401 (stddev of average 233)
>> patchset v11: 42
pt a 0.7%
> regression of the uncontended case to benefit the contended case here...
I don't know what exactly Pavel meant, but average overall numbers for
low concurrency are.
master: 420401 (stddev of average 233)
patchset v11: 420111 (stddev of average 199)
The difference is less than 0.1% and that
On Thu, Mar 2, 2023 at 11:16 PM Alexander Korotkov wrote:
> On Thu, Mar 2, 2023 at 9:17 PM Pavel Borisov wrote:
> > On Thu, 2 Mar 2023 at 18:53, Alexander Korotkov
> > wrote:
> > > On Thu, Mar 2, 2023 at 1:29 PM Pavel Borisov
> > > wrote:
> >
On Thu, Mar 2, 2023 at 9:17 PM Pavel Borisov wrote:
> On Thu, 2 Mar 2023 at 18:53, Alexander Korotkov wrote:
> > On Thu, Mar 2, 2023 at 1:29 PM Pavel Borisov wrote:
> > > > Let's see the performance results for the patchset. I'll properly
> > > > revise the
ch extracted separately.
Please, add it to the performance comparison. Thanks.
--
Regards,
Alexander Korotkov
0001-Allow-locking-updated-tuples-in-tuple_update-and-v12.patch
Description: Binary data
t; It's also not clear that change is right directionally. If we want to avoid
> re-fetching the "original" row version, why don't we provide that
> functionality via table_tuple_lock()?
These are two distinct optimizations. Now, they come as two distinct patches.
> On 2023-01-09
It doesn't sound like this is likely to get committed this release
> cycle unless responding to Andres's points simpler than I expect.
I wouldn't think ahead that much.
--
Regards,
Alexander Korotkov
Hi, Pavel!
On Mon, Jan 9, 2023 at 1:41 PM Pavel Borisov wrote:
> On Mon, 9 Jan 2023 at 13:29, Alexander Korotkov wrote:
> > On Mon, Jan 9, 2023 at 1:10 PM Alexander Korotkov
> > wrote:
> > > On Mon, Jan 9, 2023 at 12:56 PM Aleksander Alekseev
> > > w
On Mon, Jan 9, 2023 at 1:10 PM Alexander Korotkov wrote:
> On Mon, Jan 9, 2023 at 12:56 PM Aleksander Alekseev
> wrote:
> > > I'm going to push this if no objections.
> >
> > I took a fresh look at the patch and it LGTM. I only did a few
> > cosmetic changes,
It appears that I've applied changes
proposed by Mason to v5, not v6. That lead to comment mismatch with
the code that you've noticed. v8 should be correct. Please, recheck.
--
Regards,
Alexander Korotkov
0001-Allow-locking-updated-tuples-in-tuple_update-and--v8.patch
Description: Binary data
tuple was
concurrently updated, the we lock it. Once we lock, nobody can change
it until we finish out work. So, I think no changes needed.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
0001-Allow-locking-updated-tuples-in-tuple_update-and--v6.patch
Description: Binary data
On Sun, Jan 8, 2023 at 7:08 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push this and backpatch to all supported versions if no
> > objections.
>
> Push yes, but I'd counsel against back-patching. People don't
> generally like unexpected plan ch
On Tue, Dec 6, 2022 at 1:22 PM Ronan Dunklau wrote:
> Le vendredi 2 décembre 2022, 13:58:27 CET Ronan Dunklau a écrit :
> > Le vendredi 2 décembre 2022, 12:33:33 CET Alexander Korotkov a écrit :
> > > Hi, Ronan!
> > > Thank you for your patch. Couple of quick que
On Wed, Jan 4, 2023 at 5:05 PM Alexander Korotkov wrote:
> On Wed, Jan 4, 2023 at 3:43 PM Pavel Borisov wrote:
> > One more update of a patchset to avoid compiler warnings.
>
> Thank you for your help. I'm going to provide the revised version of
> patch with comments
ou. I've pushed my version, which is split into two commits.
--
Regards,
Alexander Korotkov
Hi, Pavel!
On Wed, Jan 4, 2023 at 3:43 PM Pavel Borisov wrote:
> On Wed, 4 Jan 2023 at 12:52, Pavel Borisov wrote:
> > On Wed, 4 Jan 2023 at 12:41, vignesh C wrote:
> > >
> > > On Fri, 1 Jul 2022 at 16:49, Alexander Korotkov
> > > wrote:
> > > &g
On Tue, Jan 3, 2023 at 5:28 PM Justin Pryzby wrote:
> On Tue, Jan 03, 2023 at 09:29:00AM +0300, Alexander Korotkov wrote:
> > On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > > I also suggest that meson.build should not copy regress_args.
> >
> > Good
On Tue, Jan 3, 2023 at 11:51 AM Pavel Borisov wrote:
> On Tue, 3 Jan 2023 at 09:29, Alexander Korotkov wrote:
> >
> > On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> > > On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> > > > I'm
On Mon, Jan 2, 2023 at 6:42 PM Justin Pryzby wrote:
> On Mon, Jan 02, 2023 at 06:14:48PM +0300, Alexander Korotkov wrote:
> > I'm going to push this if no objections.
>
> I also suggest that meson.build should not copy regress_args.
Good point, thanks.
--
Regards,
Alexander
to you!
--
Regards,
Alexander Korotkov
ushed the fix for this in beecbe8e5001. So no
> worries, it it not needed anymore.
OK. Thank you for keeping eyes on buildfarm.
--
Regards,
Alexander Korotkov
On Wed, Dec 7, 2022 at 4:36 PM Alexander Korotkov wrote:
> On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> > On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov
> > wrote:
> > >
> > > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > > wrote:
On Wed, Dec 7, 2022 at 1:28 AM Pavel Borisov wrote:
> On Tue, 6 Dec 2022 at 19:01, Alexander Korotkov wrote:
> >
> > On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov
> > wrote:
> > > On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > > > Alvaro Herr
On Mon, Dec 5, 2022 at 10:32 PM Alexander Korotkov wrote:
> On Mon, Dec 5, 2022 at 8:18 PM Tom Lane wrote:
> > Alvaro Herrera writes:
> > > I couldn't find any discussion of the idea of adding "(s)" to the
> > > variable name in order to mark the variabl
On Fri, Dec 2, 2022 at 6:18 PM Alexander Korotkov wrote:
> On Mon, Nov 28, 2022 at 1:30 PM Aleksander Alekseev
> wrote:
> > Thanks for the feedback!
> >
> > > I think it's a nice catch and worth fixing. The one thing I don't
> > > agree with is using ass
is change requires a catversion bump.
I've reflected this in the commit message.
> Better to add a bool column to the catalog.
What about adding a boolean array to the pg_db_role_setting? So,
pg_db_role_setting would have the following columns.
* setdatabase oid
* setrole oid
* setconfig text[]
* setuser bool[]
--
Regards,
Alexander Korotkov
e enhancements to comments, tests, and commit message.
--
Regards,
Alexander Korotkov
0001-Add-USER-SET-parameter-values-for-pg_db_role_sett-v6.patch
Description: Binary data
On Thu, Dec 1, 2022 at 6:14 AM Alexander Korotkov wrote:
> On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> > So from my side this all looks good!
>
> Thank you for your feedback.
>
> The next revision of the patch is attached. It contains code
> improvements, co
xtra if's in the release builds doesn't worth it. Personally I
> wouldn't mind using ereport() but my intuition tells me that the
> committers are not going to approve this :)
>
> Let's see what the rest of the community thinks.
I think this is harmless assertion patch. I'm going to push this if
no objections.
--
Regards,
Alexander Korotkov
On Sat, Nov 26, 2022 at 2:05 PM Ian Lawrence Barwick wrote:
> 2022年11月22日(火) 5:50 Alexander Korotkov :
> >
> > On Mon, Nov 21, 2022 at 4:34 PM Pavel Borisov
> > wrote:
> > > The following review has been posted through the commitfest application:
> > > m
p cost" – should this
be dependent on number of search entries?
--
Regards,
Alexander Korotkov
eem to be well-covered with
tests. I will probably need to write a new module into
src/tests/modules to check now placeholders interacts with dynamically
defined GUCs.
--
Regards,
Alexander Korotkov
0001-ALTER-ROLE-.-SET-.-TO-.-USER-SET-v2.patch
Description: Binary data
On Tue, Nov 22, 2022 at 12:01 AM Andres Freund wrote:
> On November 21, 2022 12:58:16 PM PST, Alexander Korotkov
> wrote:
> >On Mon, Nov 21, 2022 at 2:10 AM Andres Freund wrote:
> >> On 2022-11-20 17:26:11 -0500, Robert Haas wrote:
> >> > On Sun, Nov 20, 202
vent. And wouldn't really describe spinlocks as a whole,
> just the "extreme" delays. If we wanted to report the spin waits more
> granular, we'd presumably have to fit the wait events into the lwlock, buffers
> and some new category where we name individual spinlocks.
+1 for making a group of individual names spin delays.
--
Regards,
Alexander Korotkov
ch could
affect anybody.
I'm going to push this if there are no objections.
--
Regards,
Alexander Korotkov
.On Sun, Nov 20, 2022 at 8:48 PM Alexander Korotkov
wrote:
> I've drafted a patch implementing ALTER ROLE ... SET ... TO ... USER SET
> syntax.
>
> These options are working only for USERSET GUC variables, but require
> less privileges to set. I think there is no problem to imp
On Sat, Nov 19, 2022 at 4:02 AM Alexander Korotkov wrote:
> On Sat, Nov 19, 2022 at 12:41 AM Tom Lane wrote:
> > ... BTW, re-reading the commit message for a0ffa885e:
> >
> > One caveat is that PGC_USERSET GUCs are unaffected by the SET privilege
> > --- one
ROLE,
then we might just check permissions for such parameters from the
target role.
--
Regards,
Alexander Korotkov
On Sat, Nov 19, 2022 at 12:33 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > This makes sense. But do we really need to store the OID of the role?
> > validate_option_array_item() already checks if the placeholder option
> > passes validation for PGC_SUSET. So, we
e the OID of the role?
validate_option_array_item() already checks if the placeholder option
passes validation for PGC_SUSET. So, we can just save a flag
indicating that this check was not successful. If so, then the value
stored can be only used for PGC_USERSET. Do you think this would be
correct?
--
Regards,
Alexander Korotkov
is one of the leaders
before ~200 connections, and 1x1ms is once of the leaders after. We
could implement simple heuristics to switch between 1 and 2 retries
similar to what we have to spin delays. But let's have ARM results
first.
Links
1. https://akorotkov.github.io/blog/2021/04/30/arm/
--
Regards,
Alexander Korotkov
at starts a thread for each physical core and
> just increments a counter on an atomic value.
Thank you for this insight! I didn't know xadd is much cheaper than
cmpxchg unless there are retries. I also wonder how cmpxchg becomes
faster with higher concurrency.
--
Regards,
Alexander Korotkov
almost the same percentage for exclusive lockers!).
Pavel, could you also measure the average time LWLockWaitListLock()
spends with pg_usleep()?
It's a bit discouraging that sleeping on semaphores is so slow that
even manual fixed-time sleeping is faster. I'm not sure if this is the
issue of semaphores or the multi-process model. If we don't change
this, then let's try with multiple lock tries as Pavel proposed.
--
Regards,
Alexander Korotkov
on average.
> I suspect it might be worth going halfway, i.e. put the list head/tail in the
> atomic variable, but process the list with a lock held, after the lock is
> released.
Good idea. We, anyway, only allow one locker at a time to process the queue.
--
Regards,
Alexander Korotkov
+1
Michel, it seems that you now have a green light to implement node to
json function.
--
Regards,
Alexander Korotkov
rateful for your guidance. Thank you.
--
Regards,
Alexander Korotkov
imate the whole scan cost. Instead, I propose writing better estimations
for both entry-tree CPU cost and data-trees CPU cost and replacing existing
CPU estimation altogether.
--
Regards,
Alexander Korotkov
On Tue, Sep 20, 2022 at 1:00 PM Alexander Korotkov wrote:
> On Tue, Sep 20, 2022 at 7:48 AM Tom Lane wrote:
> > Peter Geoghegan writes:
> > > On Mon, Sep 19, 2022 at 8:39 PM Tom Lane wrote:
> > >> Our existing format is certainly not great on those metrics, but
the custom binary format looks perfect.
2) Robustness in the case of corruption. It seems much easier to
detect the data corruption and possibly make some partial manual
recovery for textual format.
3) Standartness. It's better to use something known worldwide or at
least used in other parts of Post
tabs. Please consider either manually fixing this or running
pgindent over modified files.
--
Regards,
Alexander Korotkov
Hi!
On Tue, Feb 23, 2021 at 3:09 AM Peter Geoghegan wrote:
> On Tue, Dec 8, 2020 at 2:42 AM Alexander Korotkov
> wrote:
> > Thank you for your feedback!
>
> It would be nice to use this patch to test things that are important
> but untested inside vacuumlaz
but noticeable positive effect of the patch. I'll continue
working on the patch bringing it into more acceptable shape.
--
Regards,
Alexander Korotkov
> Hi, hackers!
>
> I've looked through a new v6 of a patchset and find it ok. When applied
> 0001+0002 only I don't see warnings anymore. Build and tests are successful
> and Cfbot also looks good. I've marked the patch as RfC.
Thank you, pushed!
--
Regards,
Alexander Korotkov
Hi, John!
On Thu, Jul 21, 2022 at 6:44 AM John Naylor
wrote:
> On Tue, Jul 12, 2022 at 3:23 PM Alexander Korotkov
> wrote:
> > There are some places, which potentially could cause a slowdown. I'm
> > going to make some experiments with that.
>
> I haven't looked at
Hi!
On Tue, Jul 19, 2022 at 4:47 AM Michael Paquier wrote:
> On Mon, Jul 18, 2022 at 01:53:21PM +0300, Alexander Korotkov wrote:
> > Looks good to me as well. I'm going to push this if no objections.
>
> FWIW, I find the extra mention of PGOPTIONS with the specific point of
&g
;
>>
>> I've attached a documentation patch that mentions and links to the PGOPTIONS
>> documentation per your suggestion. I'll keep the other patch on the back
>> burner, perhaps in the future there will be demand for a command line option
>> as more TAMs are created.
>>>
>>>
>
> The documentation change looks good to me
Looks good to me as well. I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
Please, check Alvaro's advise to run "git clean -dfx". Helped to me.
--
Regards,
Alexander Korotkov
On Wed, Jul 13, 2022 at 3:19 PM Alvaro Herrera wrote:
> On 2022-Jul-13, Alexander Korotkov wrote:
>
> > results in an error
> >
> > .../src/pgbld/../postgresql/src/include/utils/elog.h:73:10: fatal
> > error: utils/errcodes.h: No such file or directory
> >
ange to me that I'm the first one discovering this. Am I
missing something?
--
Regards,
Alexander Korotkov
fix_errcodes_external_build.patch
Description: Binary data
ted by the patch?
This patch is not intended to change some high-level logic. On the
high level transaction, which updated the row, still holding a lock on
it until finished. The possible positive performance impact I expect
from doing the work of two calls tuple_update() and tuple_lock() in
the one call of tuple_update(). If we do this in one call, we can
save some efforts, for instance lock the same buffer once not twice.
--
Regards,
Alexander Korotkov
On Thu, Jul 7, 2022 at 1:43 PM Alexander Korotkov wrote:
> On Thu, Jul 7, 2022 at 2:16 AM Steve Chavez wrote:
> > Thanks Alexander!
> >
> > wrt to the new patch. I think the following comment is misleading since
> > keyDeleted can be true or false:
> >
> >
nk you for catching this.
The revised version of patch is attached!
--
Regards,
Alexander Korotkov
0001-Use-C99-designator-in-the-rbtree-sentinel-definit-v3.patch
Description: Binary data
0002-Add-missing-inequality-searches-to-rbtree-v3.patch
Description: Binary data
On Wed, Jul 6, 2022 at 8:45 PM Alexander Korotkov wrote:
> > > From b06bcb5f3666f0541dfcc27c9c8462af2b5ec9e0 Mon Sep 17 00:00:00 2001
> > > From: Alexander Korotkov
> > > Date: Wed, 22 Jun 2022 21:48:05 +0300
> > > Subject: [PATCH v2 6/6] Split tuple
orter.
>
> > Could you please extract this change as a separate patch.
>
> Done!
Thank you!
I did some improvements to the test suite, run pgindent and wrote
commit messages.
I think this is quite straightforward and low-risk patch. I'm going
to push it if no objections.
--
R
> > From 1d78e271b22d7c6a1557defbe15ea5039ff28510 Mon Sep 17 00:00:00 2001
> > From: Alexander Korotkov
> > Date: Tue, 21 Jun 2022 14:03:13 +0300
> > Subject: [PATCH v2 2/6] Tuplesortstate.getdatum1 method
>
> Hm. This adds a bunch of indirect function calls were there previously
> weren't.
Yep
-fetch the old
tuple, when it should be exactly the same tuple we've just locked.
I'm going to check the performance impact. Thoughts and feedback are welcome.
--
Regards,
Alexander Korotkov
0001-Lock-updated-tuples-in-tuple_update-and-tuple_del-v1.patch
Description: Binary data
at and use a custom node to provide some custom type of scan. The
ability to set a custom slot would save us from tuple format
conversion (thank happened to me while working on OrioleDB). I think
other users of custom nodes may also benefit.
--
Regards,
Alexander Korotkov
0001-Allow-specification
_matches?
> Also I refactored the sentinel used in the rbtree.c to use C99 designators.
Could you please extract this change as a separate patch.
--
Regards,
Alexander Korotkov
t; To mention that was perhaps unwise of me because The IDENT_P (or more
> generally, *_P) messages can be provoked on 14 too. I just thought
> 'invalid token' might be a better message because 'token' gives a more
> direct association with 'errors during parsing' which I assume is the
> case here.
>
> IDENT_P or ANY_P convey exactly nothing.
+1
--
Regards,
Alexander Korotkov
set.
Thank you for fixing this.
> Overall, I consider this patchset useful. Any opinions?
Thank you.
--
Regards,
Alexander Korotkov
shouldn't be a subject
for backpatch. The existing extensions will benefit by simplification
of maintenance for PG 16+ releases. I think that's all we can do.
--
Regards,
Alexander Korotkov
've noticed far more dramatic effect on high number of clients.
Could you verify that?
https://akorotkov.github.io/blog/2021/04/30/arm/
--
Regards,
Alexander Korotkov
or messages eventually. Please let us know
> > what you think.
>
> This is not a question of simplification. Translatable messages with
> embedded macros won't work. This patch isn't going to be acceptable.
I've suspected this, but wasn't sure. Thank you for clarification.
--
Regards,
Alexander Korotkov
> what you think.
I'm not a localization expert. Could you clarify what localization
messages should look like if we switch to XID_FMT? And will we have
to change them if change the definition of XID_FMT?
--
Regards,
Alexander Korotkov
On Thu, Mar 10, 2022 at 6:39 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Good. The revised patch is attached. Instead of adding argument to
> > LTREE_GET_ASIGLEN(), it introduces separate LTREE_GET_SIGLEN() and
> > LTREE_GET_ASIGLEN() macros.
>
> Um ..
On Tue, Mar 8, 2022 at 2:05 AM Alexander Korotkov wrote:
> On Sun, Mar 6, 2022 at 8:28 PM Tomas Vondra
> wrote:
> > On 3/6/22 08:09, Alexander Korotkov wrote:
> > > Sorry for this terrible oversight by me.
> > >
> > > On Sat, Mar 5, 2022 at 10:13 AM Tomas V
On Sun, Mar 6, 2022 at 8:28 PM Tomas Vondra
wrote:
> On 3/6/22 08:09, Alexander Korotkov wrote:
> > Sorry for this terrible oversight by me.
> >
> > On Sat, Mar 5, 2022 at 10:13 AM Tomas Vondra
> > wrote:
> >> On 3/4/22 23:09, Nikita Glukhov wrote:
>
s not invalidate relation's opclass options cache.
> >
>
> Seems like that.
I think opclass options procedure shouldn't normally change opclass
options chache. Before installation of options procedure, there
should be no options. And options procedure shouldn't change the
defaults in this case.
--
Regards,
Alexander Korotkov
bed to the pgsql-hackers mailing list?
AFAIK, moderation is only applied for non-subscribers.
--
Regards,
Alexander Korotkov
On Thu, Feb 10, 2022 at 2:35 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I've rechecked that the now patched code branch is covered by
> > regression tests. I think the memory leak issue is independent of the
> > computational errors we've observed.
>
On Thu, Feb 10, 2022 at 1:19 AM Aliaksandr Kalenik wrote:
> On Mon, Feb 7, 2022 at 11:20 PM Alexander Korotkov
> wrote:
> > Regarding the memory leak, could you add a corresponding regression
> > test to the patch (probably similar to Tom's query upthread)?
>
> Yes, adde
t compilers and optimization levels?
Regarding the memory leak, could you add a corresponding regression
test to the patch (probably similar to Tom's query upthread)?
--
Regards,
Alexander Korotkov
previous benchmarks:
> https://github.com/mngr777/pg_index_bm2
>
> Sorted build method description has been added in GiST README.
Thank you for the revision. This patch looks good to me. I've
slightly adjusted comments and formatting and wrote the commit
message.
I'm going to push
re" approach was the first tried.
https://github.com/postgrespro/pg_pageprep
But it appears to be very difficult and unreliable. After investing
many months into pg_pageprep, "double xmax" approach appears to be
very fast to implement and reliable.
--
Regards,
Alexander Korotkov
Hi!
On Thu, Jan 6, 2022 at 3:02 AM Bruce Momjian wrote:
>
> On Thu, Dec 30, 2021 at 03:15:16PM +0300, Maxim Orlov wrote:
> > PFA updated working patch v6 for PG15 development cycle.
> > It is based on a patch by Alexander Korotkov version 5 [5] with a few fixes,
> > ref
y bad
penalty as very good (or vise versa). But it still affects only index
quality, not correctness.
Any thoughts?
--
Regards,
Alexander Korotkov
use just uint32
instead of pg_atomic_uint32.
--
Regards,
Alexander Korotkov
Hi!
On Fri, Nov 5, 2021 at 10:31 AM Kyotaro Horiguchi
wrote:
> At Thu, 4 Nov 2021 01:07:05 +0300, Alexander Korotkov
> wrote in
> > On Wed, Nov 3, 2021 at 8:51 PM Simon Riggs
> > wrote:
> > > It is however, an undocumented modularity violation. I think that
message. Let me know if you have further
suggestions.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
0001-Reset-lastOverflowedXid-on-standby-when-needed.patch
Description: Binary data
me for
ExpireOldKnownAssignedTransactionIds() indicating that it could modify
lastOverflowedXid as well. Any ideas?
Should ExpireAllKnownAssignedTransactionIds() be also involved here?
--
Regards,
Alexander Korotkov
Requirements for single-copy atomicity" and it seemed
> like we should turn this on for __aarch64__. It goes back to the
> original ARMv8-A so should cover all 64 bit ARM systems.
That should be very good because ARM gains popularity and the effect
of atomic read is significant
--
Regards,
Alexander Korotkov
poning it. Leave the options immutable, until we get some solid
use-cases of mutable options.
--
Regards,
Alexander Korotkov
301 - 400 of 1179 matches
Mail list logo
