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
compress. Then, 0002 would apply this to temporary file
compression.
--
Regards,
Alexander Korotkov
Supabase
ess items array lazily. But could we leave
just items-related fields in GinBuffer, but have the rest always in
GinBuffer.cached? So, if GinBuffer.items != NULL then we have items
decompressed already, otherwise have to decompress them when needed.
--
Regards,
Alexander Korotkov
Supabase
when there is not a huge amount of free memory. So, failure
is probable on DSA allocation. Could we do simpler? For instance,
allocate some amount of static shared memory and use it as a message
queue between processes. As a heavy load is not supposed to be here,
I think one queue would be enough.
--
Regards,
Alexander Korotkov
Supabase
On Fri, Mar 7, 2025 at 5:08 PM Alexander Korotkov wrote:
> On Sun, Mar 2, 2025 at 1:58 PM Alexander Korotkov
> wrote:
> >
> > On Fri, Feb 28, 2025 at 3:13 PM Álvaro Herrera
> > wrote:
> > > On 2025-Feb-28, Michael Paquier wrote:
> > >
> > >
On Mon, Mar 10, 2025 at 1:12 PM Álvaro Herrera wrote:
> On 2025-Mar-09, Alexander Korotkov wrote:
>
> > After second thought it's not so hard to fix. The attached patch does
> > it by putting REINDEX commands related to the same table into a single
> > SQL statem
On Fri, Feb 28, 2025 at 3:55 PM Yura Sokolov wrote:
> 28.02.2025 16:03, Yura Sokolov пишет:
> > 17.02.2025 00:27, Alexander Korotkov wrote:
> >> On Thu, Feb 6, 2025 at 10:31 AM Yura Sokolov
> >> wrote:
> >>> I briefly looked into patch and have couple o
On Sun, Mar 9, 2025 at 4:53 AM Alexander Korotkov wrote:
> On Sat, Mar 8, 2025 at 12:49 PM Alexander Korotkov
> wrote:
> > On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera
> > wrote:
> > >
> > > On 2024-Mar-25, Alexander Korotkov wrote:
> > >
> &
On Wed, Mar 5, 2025 at 4:43 AM Alexander Korotkov wrote:
>
> On Mon, Mar 3, 2025 at 10:24 AM Andrei Lepikhov wrote:
> > On 17/2/2025 01:34, Alexander Korotkov wrote:
> > > Hi, Andrei!
> > >
> > > On Tue, Oct 8, 2024 at 8:00 AM Andrei Lepikhov wrote:
> &
On Wed, Mar 5, 2025 at 1:20 PM Alexander Korotkov wrote:
> On Wed, Mar 5, 2025 at 8:32 AM Andrei Lepikhov wrote:
> > On 5/3/2025 03:27, Alexander Korotkov wrote:
> > > On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
> > >>> 2. As usage of root->t
On Sat, Mar 8, 2025 at 12:49 PM Alexander Korotkov wrote:
> On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera wrote:
> >
> > On 2024-Mar-25, Alexander Korotkov wrote:
> >
> > > reindexdb: Add the index-level REINDEX with multiple jobs
> > >
> > > Strai
; barrier in case CAS fails.
Thank you, I'm good with this solution. Can I leave this on you? I'm
not feeling myself strong to word this correctly.
--
Regards,
Alexander Korotkov
Supabase
Hi, Andres!
On Fri, Mar 7, 2025 at 7:54 PM Alexander Korotkov
wrote:
> On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> > On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund
wrote:
> > > > On 2025-0
On Fri, Mar 7, 2025 at 8:20 PM Álvaro Herrera wrote:
>
> On 2024-Mar-25, Alexander Korotkov wrote:
>
> > reindexdb: Add the index-level REINDEX with multiple jobs
> >
> > Straight-forward index-level REINDEX is not supported with multiple jobs as
> > we cannot con
ready used in some user scripts. Should we
replace pg_fatal() with some notice and then run in a single job? So,
user scripts wouldn't error out.
--
Regards,
Alexander Korotkov
Supabase
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investi
On Fri, Mar 7, 2025 at 7:46 PM Andres Freund wrote:
> On 2025-03-07 19:44:20 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> > > On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > > > On Fri, Mar 7, 2025 a
On Fri, Mar 7, 2025 at 7:38 PM Andres Freund wrote:
> On 2025-03-07 19:15:23 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > > What is the access pattern and the observed problems with it that made you
> > > look at the disa
On Fri, Mar 7, 2025 at 7:15 PM Alexander Korotkov wrote:
>
> On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> > On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > > >
> > > > On
On Fri, Mar 7, 2025 at 7:07 PM Andres Freund wrote:
> On 2025-03-07 18:39:42 +0200, Alexander Korotkov wrote:
> > On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
> > >
> > > On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > > > While investi
Hi, Andres.
Thank you for reply.
On Fri, Mar 7, 2025 at 6:02 PM Andres Freund wrote:
>
> On 2025-03-07 17:47:08 +0200, Alexander Korotkov wrote:
> > While investigating a bug in the patch to get rid of WALBufMappingLock, I
> > found that the surrounding pg_atomic_compare_ex
need explicit memory barriers now.
Any thoughts?
Links
1.
https://www.postgresql.org/message-id/CAPpHfdsWcQb-u-9K%3DipneBf8CMhoUuBWKYc%2BXWJEHVdtONOepQ%40mail.gmail.com
2. https://developer.arm.com/documentation/100941/0101/Barriers
--
Regards,
Alexander Korotkov
Supabase
On Sun, Mar 2, 2025 at 1:58 PM Alexander Korotkov wrote:
>
> On Fri, Feb 28, 2025 at 3:13 PM Álvaro Herrera
> wrote:
> > On 2025-Feb-28, Michael Paquier wrote:
> >
> > > Saying that, I have also done similar tests with your v12 for a couple
> > &g
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 we too restrictive while requiring is_simple_values_sequence()?
>> For instance, I believe cases like this (containing Var) co
On Wed, Mar 5, 2025 at 8:32 AM Andrei Lepikhov wrote:
> On 5/3/2025 03:27, Alexander Korotkov wrote:
> > On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
> >>> 2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
> >>> do you think we c
On Mon, Mar 3, 2025 at 10:24 AM Andrei Lepikhov wrote:
> On 17/2/2025 01:34, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > On Tue, Oct 8, 2024 at 8:00 AM Andrei Lepikhov wrote:
> > Thank you for your work on this subject. I agree with the general
> > di
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
>
> On 2/3/2025 09:53, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > On Fri, Dec 6, 2024 at 10:13 AM Andrei Lepikhov wrote:
> >>
> >> On 12/6/24 13:48, Andrei Lepikhov wrote:
> >>>
only
> tested the patch and it was stable while I've noticed a few diffs with
> the previous version, but I did *not* check its internals at all, nor
> do I mean that I endorse its logic. I hope that's clear now.
Got it. Michael, thank you very much for your help.
--
Regards,
Alexander Korotkov
Supabase
t tests looks much more
stable now. I think he is absolutely correct with this.
--
Regards,
Alexander Korotkov
Supabase
sure this wouldn't affect other
callers of this function?
2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
do you think we could limit this to some simple cases? For instance,
check that RelOptInfo is the final result relation for given root.
Links.
https://www.postgresql.org/message-id/871q0fvbje.fsf%40163.com
--
Regards,
Alexander Korotkov
Supabase
ke the startup cost as
> cost to retrieve cost for the first tuple, we can do the below quick hack,
>
> @@ -355,8 +355,8 @@ cost_seqscan(Path *path, PlannerInfo *root,
> }
>
> path->disabled_nodes = enable_seqscan ? 0 : 1;
> - path->startup_cost = startup_cost;
> path->total_cost = startup_cost + cpu_run_cost + disk_run_cost;
> + path->startup_cost = startup_cost + (cpu_run_cost + disk_run_cost)
> * (1 - path->rows / baserel->tuples);
> }
You can check I've already proposed similar change years before.
https://www.postgresql.org/message-id/CAPpHfdvfDAXPXhFQT3Ww%3DkZ4tpyAsD07_oz8-fh0%3Dp6eckEBKQ%40mail.gmail.com
It appears that according to the current model startup_cost is not the
cost of the first tuple. It should be the cost of preparation work,
while extraction of tuples should be distributed uniformly through
total_cost - startup_cost.
--
Regards,
Alexander Korotkov
Supabase
the same
as posted by Michael from batta. My apologies for committing not
well-tested patch.
--
Regards,
Alexander Korotkov
Supabase
On Mon, Feb 24, 2025 at 2:22 PM Andrei Lepikhov wrote:
>
> On 24/2/2025 11:57, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > Thank you for your feedback.
> >
> > On Mon, Feb 24, 2025 at 12:12 AM Andrei Lepikhov wrote:
> >> On 23/2/2025 22:15
On Mon, Feb 24, 2025 at 12:57 PM Alexander Korotkov
wrote:
> On Mon, Feb 24, 2025 at 12:12 AM Andrei Lepikhov wrote:
> > On 23/2/2025 22:15, Alexander Korotkov wrote:
> > > There is my attempt to implement this approach. Getting rid of local
> > > variable (and co
1 - 100 of 1199 matches
Mail list logo
