ps://www.postgresql.org/message-id/CACJufxHHnJm6Jb2YQpuRU1RX__tO%3DJJNJ5%3DEUMuzif_KNxGd9A%40mail.gmail.com
2.
https://www.postgresql.org/message-id/CA%2BTgmoY0%3DbT_xBP8csR%3DMFE%3DFxGE2n2-me2-31jBOgEcLvW7ug%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
;t think ignoring a warning is
an option. The tests contain locale-sensitive orderings. Thus, if we
don't manage to create a C-like locale, tests fail anyway for me.
Ignoring tests is an unfavorable solution.
I see two (better) options to resolve this issue:
1) Specify LOCALE_PROVIDER='builtin' in the CREATE DATABASE command.
2) Specify 'en-US-u-va-posix' as a locale name when template0 has an
ICU locale provider.
The #1 looks simpler. The patch is attached. What do you think?
--
Regards,
Alexander Korotkov
Supabase
pg_regress_locale_provider.patch
Description: Binary data
On Tue, Jul 22, 2025 at 2:13 PM Andrei Lepikhov wrote:
>
> On 4/6/2025 00:41, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov
wrote:
> >> For me, it seems like a continuation of the 7d8ac98 discussion. We may
> >> charge a small fee
ust limits the
> > maximum size of the checkpointer requests queue.
>
> LGTM.
Good, thank you.
I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
Supabase
s.
The patch for stable branches is also attached: it just limits the
maximum size of the checkpointer requests queue.
Links.
1.
https://www.postgresql.org/message-id/CABPTF7XSSecQ-k7k9cQJsA3ACHmCVwdoRfv4DxOMom4cNQL%3D5Q%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
v8-0001
On Mon, Jul 21, 2025 at 11:40 AM vignesh C wrote:
>
> On Mon, 21 Jul 2025 at 11:04, Amit Kapila wrote:
> >
> > On Fri, Jul 18, 2025 at 5:11 PM Alexander Korotkov
> > wrote:
> > >
> > > While working on the patch fixing the situation when slot's
On Sat, Jul 19, 2025 at 10:49 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I went trough the patchset. Everything looks good to me. I only did
> > some improvements to comments and commit messages. I'm going to push
> > this if no objections.
>
> There
On Fri, Jul 18, 2025 at 2:40 PM Alexander Korotkov wrote:
> While working on the patch fixing the situation when slot's
> restart_lsn ends up pointing to a removed WAL segment [1], we
> discovered that sometimes slot's restart_lsn can go backward
> [2][3][4]. Hayato Kuro
On Fri, Jul 18, 2025 at 5:34 PM Tender Wang wrote:
> Alexander Korotkov 于2025年7月16日周三 05:56写道：
>>
>> On Wed, Jun 4, 2025 at 11:52 PM Alexander Korotkov
>> wrote:
>> > On Wed, Jun 4, 2025 at 6:15 PM Alexander Pyhalov
>> > wrote:
>> > > Alexan
On Fri, Jul 18, 2025 at 1:48 PM Amit Kapila wrote:
> On Fri, Jul 18, 2025 at 4:15 PM Alexander Korotkov
> wrote:
> >
> > On Sun, Jun 29, 2025 at 9:22 AM Hayato Kuroda (Fujitsu)
> > wrote:
> > > Thanks everyone who are working on the bug. IIUC the remained task
.org/message-id/OSCPR01MB1496634CF3BFEC3A491CF8111F547A%40OSCPR01MB14966.jpnprd01.prod.outlook.com
6.
https://www.postgresql.org/message-id/CAA4eK1%2BqYg2nwa7TVz2xN-9FDZHLUGT7NLWHtfdeaf32KN3QEQ%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
0001-Update-comment-for-last_saved_re
; I've wrote a draft for that. How do you think?
Looks good to me. I'm going to push this if no objections.
--
Regards,
Alexander Korotkov
Supabase
to go backward by fewer files:
This is indeed an interesting case. But does restart_lsn go so much
backwards in this case? I've checked the logs. It looks like standby
requested a position several segments back, but restart_lsn keeps
increasing.
> I'm ok with adding the comments.
Thank you for your feedback!
--
Regards,
Alexander Korotkov
Supabase
On Wed, Jul 16, 2025 at 1:12 AM Michael Paquier wrote:
> On Tue, Jul 15, 2025 at 09:19:50PM +0300, Alexander Korotkov wrote:
> > Thank you for your efforts on this subject. Actually, I was planning
> > to work on pushing this after the release freeze ends for v18. I'd
&g
On Wed, Jul 16, 2025 at 1:16 AM Michael Paquier wrote:
> On Wed, Jul 16, 2025 at 12:38:58AM +0300, Alexander Korotkov wrote:
> > I recently got notification this is in Open Items.
> > https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
> > What is your opinion on this:
On Wed, Jun 4, 2025 at 11:52 PM Alexander Korotkov wrote:
> On Wed, Jun 4, 2025 at 6:15 PM Alexander Pyhalov
> wrote:
> > Alexander Korotkov писал(а) 2025-06-04 14:29:
> > > On Wed, Jan 29, 2025 at 11:59 AM Maxim Orlov wrote:
> > >>
> > >> One imp
Hi, Mechael!
On Fri, Jun 27, 2025 at 3:55 PM Alexander Korotkov wrote:
> On Fri, Jun 27, 2025 at 3:26 AM Michael Paquier wrote:
> > On Thu, Jun 26, 2025 at 08:54:55AM +0200, Andrei Lepikhov wrote:
> > > Before diving into the pg_hint_plan code, I wonder why you don't ha
our efforts on this subject. Actually, I was planning
to work on pushing this after the release freeze ends for v18. I'd
like to do this at least for tests as they were initially committed by
me.
Anyway, please, hold on pushing this for ~1 day to let me do final
review of this.
--
Regards,
Alexander Korotkov
Supabase
On Sat, Jul 5, 2025 at 7:16 AM Noah Misch wrote:
>
> On Mon, Mar 31, 2025 at 09:18:30PM +0300, Alexander Korotkov wrote:
> > I'm going to push the first patch ("nowalbuf") if no objections.
>
> I completed a post-commit review of this patch. I think the patch
e_self_join_elimination available as a last
> resort method.
One thing I could additionally propose it to add hook, which gets
called before self-join elimination. If pg_hint_plan will use this
hook, it could prevent self-join elimination or track this fact in its
data structures.
On the other hand we didn't do similar thing for
remove_useless_joins(). Not sure if it's justified now.
--
Regards,
Alexander Korotkov
Supabase
compares two fields of slot. And that fields are
to be accessed anyway. So, we are not going to save any RAM accesses.
Therefore, checking for last_saved_restart_lsn_updated seems like
unnecessary code complication (and I don't see we're doing that in
other places). So, I'm going to push this patch "as is".
--
Regards,
Alexander Korotkov
Supabase
physical)
changed its last_saved_restart_lsn. See the attached patch. I'm
going to push it if no objections.
--
Regards,
Alexander Korotkov
Supabase
v1-0001-Fix-CheckPointReplicationSlots-with-max_replicati.patch
Description: Binary data
On Mon, Jun 23, 2025 at 8:04 PM vignesh C wrote:
>
> On Mon, 23 Jun 2025 at 04:36, Alexander Korotkov wrote:
> >
> > On Fri, Jun 20, 2025 at 2:24 PM vignesh C wrote:
> > > On Fri, 20 Jun 2025 at 05:54, Alexander Korotkov
> > > wrote:
> > > >
On Fri, Jun 20, 2025 at 2:24 PM vignesh C wrote:
> On Fri, 20 Jun 2025 at 05:54, Alexander Korotkov wrote:
> > Dear Kuroda-san,
> >
> > On Thu, Jun 19, 2025 at 2:05 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > > > > Regarding as
Hi, Vignesh!
On Fri, Jun 20, 2025 at 3:42 PM vignesh C wrote:
> On Fri, 20 Jun 2025 at 05:54, Alexander Korotkov wrote:
> > On Thu, Jun 19, 2025 at 2:05 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > > > > Regarding assertion fail
Could it be something similar to what I described in [2].
Namely:
1. ReplicationSlotReserveWal() sets restart_lsn for the slot.
2. Concurrent checkpoint flushes that restart_lsn to the disk.
3. PhysicalConfirmReceivedLocation() sets restart_lsn of the slot to
the beginning of the segment.
[1]
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=mamba&dt=2025-06-17%2005%3A10%3A36&stg=recovery-check
[2]
https://www.postgresql.org/message-id/CAPpHfdv3UEUBjsLhB_CwJT0xX9LmN6U%2B__myYopq4KcgvCSbTg%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
On Thu, Jun 19, 2025 at 1:29 PM Amit Kapila wrote:
> On Wed, Jun 18, 2025 at 10:17 PM Alexander Korotkov
> wrote:
> >
> > On Wed, Jun 18, 2025 at 6:50 PM Vitaly Davydov
> > wrote:
> > > > I think, it is a good idea. Once we do not use the generated dat
guarantee that restart_lsn never goes
backward. The commit in ReplicationSlotReserveWal() even states there
is a "chance that we have to retry". Thus, I propose to remove the
assertion introduced by ca307d5cec90.
Any objection from backpatching 0001 though 17 and pushing 0002 to the he
icalConfirmReceivedLocation(), then crash could cause this WAL
location to be unavailable. Is that true?
Also, what do you think about proposed changes in [1]? I wonder if it
could somehow decrease the coverage.
Links.
1.
https://www.postgresql.org/message-id/OSCPR01MB149665B3F0629D10731B18E5AF570A%40OSCPR01MB14966.jpnprd01.prod.outlook.com
--
Regards,
Alexander Korotkov
Supabase
not.
> You can check check_extension() and callers.
Thank you! All of these totally make sense. The updated patch is attached.
--
Regards,
Alexander Korotkov
Supabase
v3-0001-Improve-runtime-and-output-of-tests-for-replicati.patch
Description: Binary data
arre output, as shown in the buildfarm logs:
Thank you for reporting this. The revised patch is attached. In
addition to reducing tests runtime, it removes excess newlines from
some note() calls. The commit message is here. I'm going to push
this if no objections.
--
Regards,
Alexander
On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches. Any objections?
>
>
> As the b
Hi, Alexander!
On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches. Any objections?
>
>
states), decreases the number of locks in
> ReplicationSlotsComputeRequiredLSN - no need to recalculate oldest slots'
> restart lsn every time when a slot is advanced.
So, my proposal is to commit the attached patchset to the HEAD, and
commit [1] to the back branches. Any object
lready exists"),
+ parser_errposition(pstate, spsDef->name->location));
+ ereport(ERROR,
+ errcode(ERRCODE_CHECK_VIOLATION),
+ errmsg("can not find partition for split partition
row"),
+ errtable(splitRel));
--
Regards,
Alexander Korotkov
Supabase
On Tue, Jun 3, 2025 at 5:02 PM Alexander Korotkov wrote:
> On Wed, May 14, 2025 at 1:50 PM Andrei Lepikhov wrote:
> > On 9/12/24 16:57, Tomas Vondra wrote:
> > > On 9/12/24 12:12, David Rowley wrote:
> > >> On Thu, 12 Sept 2024 at 21:51, Andrei Lepikhov wrote:
On Wed, Jun 4, 2025 at 6:15 PM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2025-06-04 14:29:
> > On Wed, Jan 29, 2025 at 11:59 AM Maxim Orlov wrote:
> >>
> >> One important note here. This patch will change cast behaviour in case
> >> of lo
e for a foreign wrapped data.
> In any case, it's up to the committer to decide whether this change is needed
> or not.
I have two question regarding this aspect.
1) Is it the same with regular type conversion?
2) Can we fallback to remote type conversion in local type conversion fails?
On Tue, Jun 3, 2025 at 5:35 PM Andrei Lepikhov wrote:
> On 3/6/2025 16:05, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
> >> Additionally, as I mentioned earlier, the primary reason for choosing
> >> MergeAppend in the regress
On Tue, Jun 3, 2025 at 4:53 PM Andrei Lepikhov wrote:
> On 3/6/2025 15:38, Alexander Korotkov wrote:
> > On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
> >> To establish a stable foundation for discussion, I conducted simple
> >> tests - see, for example,
m_groups() might contain
either Expr's or Pathkey's. I think this should be documented.
2. A new argument relids of estimate_num_groups() also should be documented.
3. I doubt estimate_num_groups() is appropriate place to handle "varno
0". Should we do this in cost_incremental_sort() as before? I see
that it currently analyzes only first EquivalenceMember. But could it
be a different answers between first EquivalenceMember and others?
--
Regards,
Alexander Korotkov
Supabase
On Tue, Jun 3, 2025 at 4:23 PM Andrei Lepikhov wrote:
> On 2/6/2025 20:21, Alexander Korotkov wrote:
> > I have the following question. I see patch changes some existing
> > plans from Sort(Append(...)) to MergeAppend(Sort(), ..., Sort(...)) or
> > even Materialize(MergeApp
On Mon, Jun 2, 2025 at 2:53 PM Amit Kapila wrote:
>
> On Thu, May 29, 2025 at 5:29 PM Alexander Korotkov
> wrote:
> >
> > On Tue, May 27, 2025 at 2:26 PM Amit Kapila wrote:
> > > Yeah, we should be able to change ABI during beta, but I can't comment
> &g
f
CompactCheckpointerRequestQueue(), I think it's OK to integrate this
into once patch.
> > 3) For sure, we wouldn't backpatch this. Can we prepare some simple
> > solution for back branches? Perhaps, just introduction of
> > MAX_CHECKPOINT_REQUESTS is enough to save
ing ACLs. It's probably OK, and we could
introduce options for ACL handling later. But we need to state in the
docs that it's user responsibility to setup ACL on new partition(s).
--
Regards,
Alexander Korotkov
Supabase
suggest that owner of new partitions produced by ALTER TABLE ...
SPLIT should be the same as owner of original partition. Even if this
operation is done by superuser. Superuser may explicitly set he owner
if needed. I think we need to explicitly document this.
--
Regards,
Alexander Korotkov
Supabase
)). This should be
some problem in cost_sort(). Otherwise, that would mean that Sort
node doesn't know how to do its job: explicit splitting dataset into
pieces then merging sorting result appears to be cheaper, but Sort
node contains merge-sort algorithm inside and it's supposed to be more
efficient. Could you, please, revise the patch to avoid these
unwanted changes?
--
Regards,
Alexander Korotkov
Supabase
n for back branches? Perhaps, just introduction of
MAX_CHECKPOINT_REQUESTS is enough to save us from allocations larger
than 1GB.
--
Regards,
Alexander Korotkov
Supabase
o add hooks for deleting the
> database and relationships (functions dropdb, index_drop,
> heap_drop_with_catalog).
Can we workaround this with object_access_hook?
--
Regards,
Alexander Korotkov
Supabase
ion progress though. Could you get me some clue on this,
please?
Links.
1. https://www.postgresql.org/message-id/1538a2-67c5c700-7-77ec5a80%40179382871
--
Regards,
Alexander Korotkov
Supabase
On Tue, May 27, 2025 at 12:12 PM Alexander Korotkov
wrote:
>
> On Tue, May 27, 2025 at 7:08 AM Amit Kapila wrote:
> > On Mon, May 26, 2025 at 10:36 PM Alexander Korotkov
> > wrote:
> > >
> > > On Mon, May 26, 2025 at 2:43 PM Amit Kapila
> > > wro
On Tue, May 27, 2025 at 7:08 AM Amit Kapila wrote:
> On Mon, May 26, 2025 at 10:36 PM Alexander Korotkov
> wrote:
> >
> > On Mon, May 26, 2025 at 2:43 PM Amit Kapila wrote:
> > >
> > > On Mon, May 26, 2025 at 3:52 PM Vitaly Davydov
> > > wrot
r alternative
> ideas to fix this issue.
I don't understand exact concerns about this fix. For sure, we can
try to implement a fix hacking LogicalConfirmReceivedLocation() and
PhysicalConfirmReceivedLocation(). But that would be way more
cumbersome, especially if we have to keep ABI compatibility. Also, it
doesn't seem to me that either LogicalConfirmReceivedLocation() or
PhysicalConfirmReceivedLocation() currently try to address this issue:
LogicalConfirmReceivedLocation() implements immediate sync for
different reasons.
--
Regards,
Alexander Korotkov
Supabase
On Mon, May 26, 2025 at 9:49 AM Amit Kapila wrote:
>
> On Sat, May 24, 2025 at 6:59 PM Alexander Korotkov
> wrote:
> >
> > Hi, Amit!
> >
> > Thank you for your attention to this patchset!
> >
> > On Sat, May 24, 2025 at 2:15 PM Amit Kapila wrote:
&g
Hi, Amit!
Thank you for your attention to this patchset!
On Sat, May 24, 2025 at 2:15 PM Amit Kapila wrote:
> On Sat, May 24, 2025 at 4:08 PM Alexander Korotkov
> wrote:
> >
> > I spend more time on this. The next revision is attached. It
> > contains revised com
On Fri, May 23, 2025 at 12:10 AM Alexander Korotkov
wrote:
>
> Hi, Vitaly!
>
> On Tue, May 20, 2025 at 6:44 PM Vitaly Davydov
> wrote:
> >
> > Thank you very much for the review!
> >
> > > The patchset doesn't seem to build after 371f2d
upported releases as it fixes material bug, while
0002 should be backpatched to 17, where injection points fist appears.
0003 should go to pg19 after branching. I'm continuing reviewing
this.
--
Regards,
Alexander Korotkov
Supabase
From c409a441be6487063d49c2671d3a3aecb9ba6994 Mon Sep 17
ly looks good. But what about the "if
(InvalidateObsoleteReplicationSlots(...))" branch? It calls
XLogGetReplicationSlotMinimumLSN() again. Why would the value
obtained from the latter call reflect slots as they are synchronized
to the disk?
--
Regards,
Alexander Korotkov
Supabase
On Thu, May 1, 2025 at 8:22 PM Andrei Lepikhov wrote:
> On 1/5/2025 14:11, Alexander Korotkov wrote:
> > 3. Should the ChangeVarNodesWalkExpression function return the walker's
> > returning value?
> >
> >
> > Done.
> Thanks for your efforts! Lo
Hi, Andrei!
Thank you for your review!
On Wed, Apr 30, 2025 at 4:34 PM Andrei Lepikhov wrote:
> On 4/30/25 13:22, Alexander Korotkov wrote:
> >> Thank you, Andrei. I've put it all together.
> >> 0001 Fixes material bugs in ChangeVarNodes_walker() including
> r
On Sun, Apr 27, 2025 at 2:02 PM Alexander Korotkov wrote:
>
> On Fri, Apr 11, 2025 at 5:46 PM Andrei Lepikhov wrote:
> > On 4/10/25 14:39, Andrei Lepikhov wrote:
> > > On 4/10/25 13:36, Alexander Korotkov wrote:
> > >> On Wed, Apr 9, 2025 at 10:39 AM Andrei L
WaitForLSNReplay / WaitLSNWakeup
>
> I think the function comment should document the important stuff (e.g.
> return values for various situations, how it groups waiters into chunks
> of 16 elements during wakeup, ...).
Revised header comments for those functions too.
> 11) WaitLSNProcInfo
Hi, Noah!
On Tue, Apr 29, 2025 at 3:56 AM Noah Misch wrote:
> On Mon, Apr 21, 2025 at 04:54:08AM +0300, Alexander Korotkov wrote:
> > On Sat, Apr 12, 2025 at 12:43 AM Alexander Korotkov
> > wrote:
> > > On Fri, Apr 11, 2025 at 11:32 PM Noah Misch wrote:
> > >
On Tue, Apr 29, 2025 at 4:03 AM Masahiko Sawada wrote:
>
> On Mon, Apr 28, 2025 at 8:17 AM Alexander Korotkov
> wrote:
> >
> > > I have a question - is there any interest to backport the solution into
> > > existing major releases?
> >
> > As long as
ion - is there any interest to backport the solution into
> existing major releases?
As long as this is the bug, it should be backpatched to all supported
affected releases.
> I can prepare a patch where restart_lsn_flushed stored
> outside of ReplicationSlot structure and doesn't affect the existing API.
Yes, please!
--
Regards,
Alexander Korotkov
Supabase
On Fri, Apr 11, 2025 at 5:46 PM Andrei Lepikhov wrote:
> On 4/10/25 14:39, Andrei Lepikhov wrote:
> > On 4/10/25 13:36, Alexander Korotkov wrote:
> >> On Wed, Apr 9, 2025 at 10:39 AM Andrei Lepikhov
> >> wrote:
> >>> It seems we are coming to the co
On Sat, Apr 26, 2025 at 11:04 PM Alexander Korotkov
wrote:
> On Sun, Apr 6, 2025 at 12:02 AM Alena Rybakina
> wrote:
> > Should we add more regression tests covering these cases?
> >
> > I experimented with some examples like this and noticed that it does affect
&g
27;m going to push it if no objections.
--
Regards,
Alexander Korotkov
Supabase
v2-0001-Disallow-removing-placeholders-during-Self-Join-E.patch
Description: Binary data
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'd like to add that float4.out not only assumes that insert-ordering is
> > preserved (this could be more-or-less portable between table AMs). It also
> > assumes the way UPDATE moves
abs_f1 FROM FLOAT4_TBL f;
f1 |abs_f1
---+---
0 | 0
1004.3 |1004.3
-34.84 | 34.84
1.2345679e+20 | 1.2345679e+20
1.2345679e-20 | 1.2345679e-20
(5 rows)
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
SELECT * FROM FLOAT4_TBL;
f1
0
-34.84
-1004.3
-1.2345679e+20
-1.2345679e-20
(5 rows)
--
Regards,
Alexander Korotkov
Supabase
Hi, Noah!
On Sat, Apr 12, 2025 at 12:43 AM Alexander Korotkov
wrote:
>
> On Fri, Apr 11, 2025 at 11:32 PM Noah Misch wrote:
> >
> > On Tue, Oct 22, 2024 at 08:33:24PM +0300, Alexander Korotkov wrote:
> > > On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov
> > >
On Fri, Apr 11, 2025 at 11:32 PM Noah Misch wrote:
>
> On Tue, Oct 22, 2024 at 08:33:24PM +0300, Alexander Korotkov wrote:
> > On Tue, Oct 22, 2024 at 6:10 PM Pavel Borisov
> > wrote:
> > > On Tue, 22 Oct 2024 at 11:34, Alexander Korotkov
> > > wrote:
On Fri, Apr 11, 2025 at 5:06 AM Andres Freund wrote:
> On 2025-04-11 00:47:19 +0200, Matthias van de Meent wrote:
> > On Fri, 11 Apr 2025 at 00:27, Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2025-03-09 14:13:52 +0200, Alexander Korotk
move
> ChangeVarNodes out of rewriteManip and make it multi-purpose routine,
> allowing to transform expression that may happen after a Var node change?
What about adding a callback to ChangeVarNodes_context that would
called for each RestrictInfo after changing varnodes itself? SJE
could use a callback that replaces OpExpr with NullTest when needed.
--
Regards,
Alexander Korotkov
Supabase
{1,2}'::oid[]))
> > + -> Sort
> > + Sort Key: a.oid
> > + -> Seq Scan on pg_am a
> > +(7 rows)
>
> Are these failures from patches applied to master prior to 3ba2cdaa?
Yes, these failures appears before 3ba2cdaa. Tom committed 3ba2cdaa
to fix the problem before I get into it [1].
Links.
1.
https://www.postgresql.org/message-id/srnuqlttuimzmvoulhsrbgvj4vnul6b65osswvua7sfkqsvmuy%40yg7apybpxp34
--
Regards,
Alexander Korotkov
Supabase
com
Thank you for pointing. Looking into that!
--
Regards,
Alexander Korotkov
Supabase
On Fri, Apr 4, 2025 at 6:47 PM Melanie Plageman
wrote:
>
> On Fri, Apr 4, 2025 at 9:17 AM Alexander Korotkov
> wrote:
> >
> > Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
> >
> > This commit implements the automatic convers
On Sun, Apr 6, 2025 at 5:41 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Nevertheless, should we consider revisiting this flag? I see the only
> > other GUC simultaneously QUERY_TUNING_METHOD and GUC_NOT_IN_SAMPLE is
> > optimize_bounded_sort, which is not expose
GUC_NOT_IN_SAMPLE flag. Thanks for the reminder.
> Please ignore the noise.
Also, sorry for thoughtless commit of that.
Nevertheless, should we consider revisiting this flag? I see the only
other GUC simultaneously QUERY_TUNING_METHOD and GUC_NOT_IN_SAMPLE is
optimize_bounded_sort, which is not exposed in a standard build.
--
Regards,
Alexander Korotkov
Supabase
t; configurations with hundreds of clients. So, there're more bottlenecks ahead
> ))
>
>
> Yes, it is still not "real-world" benchmark. But it at least shows patch is
> harmless.
Thank you for your experiments. Your results shows up to 30% speedups
on real hardware, not tmpfs. While this is still a corner case, I
think this is quite a results for a pretty local optimization. On
small connection number there are some cases above and below 1.0. I
think this due to statistical error. If we would calculate average
tps ratio across different experiments, for low number of clients it's
still above 1.0.
sqlite> select clients, avg(ratio) from (select walseg, walbuf,
recsize, clients, (avg(tps) filter (where branch =
'nowalbuf'))/(avg(tps) filter (where branch = 'master')) as ratio from
results where branch in ('master', 'nowalbuf') group by walseg,
walbuf, recsize, clients) x group by clients;
1|1.00546614169766
4|1.00782085856889
16|1.02257892337757
64|1.04400167838906
128|1.04134006876033
256|1.04627949500578
I'm going to push the first patch ("nowalbuf") if no objections. I
think the second one ("Several attempts") still needs more work, as
there are regressions.
--
Regards,
Alexander Korotkov
Supabase
ns FALSE,
>> > !bms_is_member(var->varno, outerrel->relids) will not execute due to
>> > short circuit.
>> >
>> > So I think we can remove the "!bms_is_member(var->varno,
>> > outerrel->relids)" from if.
>> > Any thoughts?
>>
>> Hi.
>> Seems good to me.
>> --
>> Best regards,
>> Alexander Pyhalov,
>> Postgres Professional
>
>
> Thanks for looking at that.
Pushed. But I've decided to keep the redundant check as an assertion.
--
Regards,
Alexander Korotkov
Supabase
On Fri, Apr 4, 2025 at 11:35 AM Andrei Lepikhov wrote:
>
> On 4/4/25 04:53, Richard Guo wrote:
> > On Fri, Apr 4, 2025 at 1:02 AM Alexander Korotkov
> > wrote:
> >> I've got an off-list bug report from Alexander Lakhin involving a
> >> placeholder variab
not stable I think the next step is to nuke both
> test queries, since I remain of the opinion that they're likely
> a waste of cycles.
Thank you for pushing this! I just start looking at the problem and
have just seen your commit.
--
Regards,
Alexander Korotkov
Supabase
uot;unable to enable data checksums in cluster")));
2) ProcessAllDatabases() contains loop, which repeats scanning the new
databases for checkums. It continues while there are new database on each
iteration. Could we just limit the number of iterations to 2? Given at
each step we're calling WaitForAllTransactionsToFinish(), everything that
gets created after first WaitForAllTransactionsToFinish() call should have
checksums enabled in the beginning.
--
Regards,
Alexander Korotkov
Supabase
1.
https://www.postgresql.org/message-id/e3ac0535-e7a2-4a96-9b36-9f765e9cfec5%40vondra.me
--
Regards,
Alexander Korotkov
Supabase
s attached. I'm going to fix this if no objections.
--
Regards,
Alexander Korotkov
Supabase
v1-0001-Disallow-removing-placeholders-during-Self-Join-E.patch
Description: Binary data
s if no
objections.
--
Regards,
Alexander Korotkov
Supabase
v9-0001-Extract-make_SAOP_expr-function-from-match_orclau.patch
Description: Binary data
v9-0002-Convert-x-IN-VALUES-.-to-x-ANY-.-then-appropriate.patch
Description: Binary data
g Time: 0.321 ms
Execution Time: 210.409 ms
(12 rows)
Only when we have all consts in the array, we can have SAOP hashing which
is competitive with hashing of VALUES node. So, I'm continuing with my
version of patch.
Links.
1.
https://www.postgresql.org/message-id/CAPpHfds-7eJ3ZMgyeVrMfC5E1nTHD4Bp0ch5MZhrYSoiCfERXw%40mail.gmail.com
--
Regards,
Alexander Korotkov
Supabase
=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Values Scan on "*VALUES*" (cost=0.00..0.08 rows=6 width=4)
(actual time=0.009..0.032 rows=6.00 loops=1)
Planning Time: 0.627 ms
Execution Time: 225.155 ms
(12 rows)
I think we should allow our transformation only
ers: shared hit=1
-> Hash (cost=0.03..0.03 rows=2 width=32) (actual time=0.111..0.112
rows=2.00 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=32)
(actual time=0.004..0.065 rows=2.00 loops=1)
Planning Time: 0.250 ms
Execution Time: 0.267 ms
(10 rows)
--
Regards,
Alexander Korotkov
Supabase
Hi, Alena!
On Sat, Mar 29, 2025 at 9:03 PM Alena Rybakina
wrote:
> On 29.03.2025 14:03, Alexander Korotkov wrote:
>> One thing I have to fix: we must do
>> IncrementVarSublevelsUp() unconditionally for all expressions as Vars
>> could be deeper inside.
>
> Yes, I
On Wed, Mar 12, 2025 at 8:11 PM Alena Rybakina
wrote:
> On 06.03.2025 11:23, Alexander Korotkov wrote:
>
> Hi, Alena!
>
> On Sat, Mar 1, 2025 at 1:39 PM Alena Rybakina
> wrote:
>
> On 09.02.2025 18:38, Alexander Korotkov wrote:
>
> Also, aren't
On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov wrote:
> On 3/28/25 00:18, Alexander Korotkov wrote:
> > The attached patch changes the reordering algorithm of
> > group_similar_or_args() in the following way. We reorder each group
> > of similar clauses so that the first it
he
clauses remain in their places.
--
Regards,
Alexander Korotkov
Supabase
v1-0001-Make-group_similar_or_args-reorder-clause-list-as.patch
Description: Binary data
On Mon, Mar 24, 2025 at 6:56 PM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2025-03-24 11:49:
> > On Mon, Mar 24, 2025 at 9:07 AM Alexander Pyhalov
> > wrote:
> >> Alexander Korotkov писал(а) 2025-03-24 04:21:
> >> > Hi, Alexander!
> >
On Mon, Mar 24, 2025 at 9:07 AM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2025-03-24 04:21:
> > Hi, Alexander!
> >
> > On Tue, Mar 18, 2025 at 6:04 PM Alexander Pyhalov
> > wrote:
> >> This shouldn't. When semi-join is found below left/r
from semi-joins, then their
further pulls will be disabled automatically? See the attached patch.
It also contains other (mostly cosmetic improvements).
--
Regards,
Alexander Korotkov
Supabase
v2-0001-Avoid-pulling-up-restrict-infos-from-subqueries.patch
Description: Binary data
Hi, Alexander!
On Tue, Mar 18, 2025 at 1:13 PM Alexander Pyhalov
wrote:
> Alexander Korotkov писал(а) 2025-03-18 03:27:
> > Hi, Robins!
> >
> > On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan
> > wrote:
> >> On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov
On Tue, Mar 18, 2025 at 12:13 AM Tomas Vondra wrote:
> On 3/15/25 11:40, Alexander Korotkov wrote:
> > On Sun, Jan 5, 2025 at 1:43 AM Filip Janus wrote:
> >>
> >> I apologize for multiple messages, but I found a small bug in the previous
> >> version.
> &
Hi, Robins!
On Tue, Mar 18, 2025 at 2:20 AM Robins Tharakan wrote:
> On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov wrote:
> >
> >
> > Now, I think this looks good. I'm going to push this if no objections.
>
> After this commit, I began seeing an unexpe
1 - 100 of 1232 matches
Mail list logo
