On Wed, Jul 23, 2025 at 06:22:16AM +, Bertrand Drouvot wrote:
> PFA v4 where the only change compared to v3 is that it reads lwlocklist.h once
> in generate-lwlocknames.pl.
Committed.
--
nathan
On Tue, Jul 22, 2025 at 4:23 PM Masahiko Sawada wrote:
> The trend of the results were similar:
>
> getrandom: 497.061 ms
> RAND_bytes: 1152.260 ms ms
> /dev/urandom: 1696.065 ms
>
> Please let me know if I'm missing configurations or settings to
> measure this workload properly.
I don't think yo
Hello Jelte,
I reviewed your patch. Overall it looks good, I didn't find any problems
with code. Documentation is in place and clear.
Initial Run
===
The patch applies cleanly to HEAD (196063d6761). All tests successfully
pass.
Comments
===
1) I noticed that pg_dump changes weren
On 7/23/25 02:59, Andres Freund wrote:
> Hi,
>
> On 2025-07-23 02:50:04 +0200, Tomas Vondra wrote:
>> But I don't see why would this have any effect on the prefetch distance,
>> queue depth etc. Or why decreasing INDEX_SCAN_MAX_BATCHES should improve
>> that. I'd have expected exactly the opposite
Hello
I noticed some duplicative coding while hacking on REPACK[1]. We can
save a few lines now with a trivial change to the rules for CHECKPOINT
and REINDEX, and allow to save a few extra lines in that patch.
Any objections to this?
[1] https://commitfest.postgresql.org/patch/5117/
--
Álvaro
On Tue, Jul 22, 2025 at 8:24 AM Bertrand Drouvot
wrote:
> So based on the cycles metric I think it looks pretty safe to implement for
> the
> whole majority of classes.
I'm not convinced that this is either cheap enough to implement, and I
don't understand the value proposition, either. I see th
Committed. I noticed that there are several characters with no match in
protocol.h. It might be worth adding those.
In walsender.c:
1537: pq_sendbyte(ctx->out, 'w');
2353: case 'r':
2357: case 'h':
2361: case 'p':
2755: p
On Wed, Jul 23, 2025 at 05:38:34PM +0200, Álvaro Herrera wrote:
> I noticed some duplicative coding while hacking on REPACK[1]. We can
> save a few lines now with a trivial change to the rules for CHECKPOINT
> and REINDEX, and allow to save a few extra lines in that patch.
>
> Any objections to t
On 2025-Jul-23, Álvaro Herrera wrote:
> So we can still do this, and I still think it's a win, but unfortunately
> it won't help for the REPACK patch.
Ah no, I can still use it:
RepackStmt:
REPACK opt_utility_option_list qualified_name USING INDEX name
| REPACK opt_utilit
Hi,
On 2025-03-08 11:47:25 -0500, Peter Geoghegan wrote:
> My current plan is to commit this on Tuesday or Wednesday, barring any
> objections.
A minor question about this patch: Was there a particular reason it added the
index specific instrumentation information inline in IndexScanState etc? O
... so using the same set of productions, I can rewrite the current
CLUSTER rule in this way and it won't be a problem for the REPACK
changes.
Thanks for looking!
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
>From 91edb076325ca366762832fcf3a4eab7de21002d Mon
Hi,
On 2025-07-18 13:24:32 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-07-17 20:09:57 -0400, Tom Lane wrote:
> >> I made it just as a proof-of-concept that this can work. It compiled
> >> cleanly and passed check-world for me on a 32-bit FreeBSD image.
>
> > Interestingly it gener
On Wed, Jul 23, 2025 at 4:16 PM Etsuro Fujita wrote:
>
> On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita wrote:
> > Another thing I noticed about transition tables is that while we
> > prohibit transition tables on views/foreign tables, there is no
> > description about that in the user-facing docu
Hi,
On 2025-07-23 14:50:15 +0200, Tomas Vondra wrote:
> On 7/23/25 02:59, Andres Freund wrote:
> > Hi,
> >
> > On 2025-07-23 02:50:04 +0200, Tomas Vondra wrote:
> >> But I don't see why would this have any effect on the prefetch distance,
> >> queue depth etc. Or why decreasing INDEX_SCAN_MAX_BAT
On Wed, Jul 23, 2025 at 1:50 PM Andres Freund wrote:
> A minor question about this patch: Was there a particular reason it added the
> index specific instrumentation information inline in IndexScanState etc? Of
> course the amount of memory right now is rather trivial, so that is not an
> issue m
Hi,
On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
> On Tue, Jul 22, 2025 at 10:57:06AM -0400, Andres Freund wrote:
> > It seems rather unsurprising that that causes a slowdown.
> >
> > The pre-check is there to:
> > /* Don't expend a clock check if nothing to do */
> >
> > but you mad
Hi,
On 2025-07-22 11:44:29 -0700, Masahiko Sawada wrote:
> Do you think it makes sense to implement the above idea that we launch
> parallel vacuum workers for heap through the same vacuumparallel.c
> codebase and maintain the consistent interface with parallel index
> vacuuming APIs?
Yes, that m
=?UTF-8?B?0JDQvdGC0YPQsNC9INCS0LjQvtC70LjQvQ==?=
writes:
> I made patch for this problem, I changed event_trigger, for
> definitions of temporality
> DEFAULT VALUE
I looked over this patch. I understand what you want to fix,
and I agree with the general plan of pushing the namespace-lookup
code
On Mon, Jun 23, 2025 at 10:29:50AM +1000, Peter Smith wrote:
> Hi,
>
> I am looking for some guidelines/recommended SGML tags to use when
> referring in the PG documentation to any user-defined
> schema/table/column names.
>
> This is most commonly seen near a SQL example.
>
> Currently, it see
I had left plain < and > in code sample in documentation page, fixed now
On Sun, Jul 6, 2025 at 11:52 PM Hannu Krosing wrote:
>
> On Sat, Feb 3, 2024 at 8:54 AM Hannu Krosing wrote:
> >
> > My justification for adding pl/pgsql tests as part of the immediately
> > available tests
> > is that
On 3/18/25 22:37, Nathan Bossart wrote:
Committed with the following small changes:
Hi, I don't really understand this sentence in
doc/src/sgml/ref/vacuumdb.sgml:
> This option prevents vacuumdb from deleting existing statistics so
that the query optimizer's choices do not become transie
Hi,
On 2025-07-23 10:23:53 +, Bertrand Drouvot wrote:
> On Wed, Jul 23, 2025 at 05:09:54PM +0900, Michael Paquier wrote:
> > so we don’t really need to mix multiple numbers; we could just have a single
> > boolean flag that any fixed-sized stats kinds can set to let the reporting
> > know
> >
Hi,
$SUBJECT,because anyway after the next transaction starts XactReadOnly is
going to change depending on either RecoveryInProgress()
or DefaultXactReadOnly GUC ,so if there's no specific use to
set transaction_read_only GUC can we change its GucContext from PGC_USERSET
to PGC_INTERNAL and remove
Ok Thanks Daniel
It show the right value with the connection over the network
Regards
Fabrice
postgres [2867156]=> show tcp_keepalives_idle;
+-+
| tcp_keepalives_idle |
+-+
| 3 |
+-+
(1 row)
On Wed, Jul 23, 2025 at 1
On Tue, Jul 22, 2025 at 9:31 PM Peter Geoghegan wrote:
> I'll get back to you on this soon. There are plenty of indexes that
> are not perfectly correlated (like pgbench_accounts_pkey is) that'll
> nevertheless benefit significantly from the approach taken by the
> complex patch.
I'll give you a
On 2025-Jul-23, Nathan Bossart wrote:
> On Wed, Jul 23, 2025 at 05:38:34PM +0200, Álvaro Herrera wrote:
> > I noticed some duplicative coding while hacking on REPACK[1]. We can
> > save a few lines now with a trivial change to the rules for CHECKPOINT
> > and REINDEX, and allow to save a few extr
On 7/23/25 17:09, Andres Freund wrote:
> Hi,
>
> On 2025-07-23 14:50:15 +0200, Tomas Vondra wrote:
>> On 7/23/25 02:59, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2025-07-23 02:50:04 +0200, Tomas Vondra wrote:
But I don't see why would this have any effect on the prefetch distance,
queue de
On Wed, Jul 23, 2025 at 06:50:59PM +0200, Álvaro Herrera wrote:
> So we can still do this, and I still think it's a win,
+1
> but unfortunately it won't help for the REPACK patch.
Darn.
--
nathan
Andres Freund writes:
> On 2025-07-18 13:24:32 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> One class of complaints is about DatumGetPointer() and
>>> PointerGetDatum() casting between different sizes:
>> We might be able to silence those with intermediate casts to uintptr_t,
>> perhaps?
On 2024-Sep-04, Kyotaro Horiguchi wrote:
> Hello,
>
> While reviewing a patch, I noticed that enum RecoveryTargetAction is
> still in xlog_internal.h, even though it seems like it should be in
> xlogrecovery.h. Commit 70e81861fa separated out xlogrecovery.c/h and
> moved several enums related to
Dear Ajin,
Thanks for the patch. Firstly let me confirm my understanding. While altering
the
subscription, locks are acquired with below ordering:
Order target level
1 pg_subscription row exclusive
2 p
On Wed, Jul 23, 2025 at 05:09:54PM +0900, Michael Paquier wrote:
> On Jul 23, 2025, at 16:33, Bertrand Drouvot
> wrote:
> > Maybe we could use a flag, say:
> >
> > #define PGSTAT_PENDING_IO (1 << 0)
> > #define PGSTAT_PENDING_WAL(1 << 1)
> > #define PGSTAT_PENDING_SLRU (1 << 2)
> >
>
Hi,
On Sat, Jul 19, 2025 at 12:53 AM Jehan-Guillaume de Rorthais
wrote:
> We have been bitten by this old bug recently:
>
> https://www.postgresql.org/message-id/flat/CAFjFpRfcgwsHRmpvoOK-GUQi-n8MgAS%2BOxcQo%3DaBDn1COywmcg%40mail.gmail.com
>
> I suspect this bug lost attention when the only fixed
>From: Fabrice Chapuis
>Sent: Wednesday, July 23, 2025 13:20
>To: PostgreSQL Hackers
>Subject: Postgres keep alive configuration
>
>Hi,
>
>I try to configure these 3 parameters to activate keep alive on a sever
>Postgres in version 14.
>
>tcp_keepalives_idle = 3
>tcp_keepalives_interval = 2
>tc
On Wed, Jul 23, 2025 at 2:42 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Ajin,
>
> Thanks for the patch. Firstly let me confirm my understanding. While altering
> the
> subscription, locks are acquired with below ordering:
>
> Order target level
> 1
Hello,
As a very trivial test on this patch, I ran the query in your opening
email, both with and without the patch, scaling up the size of the table
a little bit. So I did this
drop table if exists t;
create table t(a int, b int);
insert into t select i % 10, i from
On 2025-Jul-22, Andrew Dunstan wrote:
> If we were making up our own syntax this would be a sensible thing to
> debate. If we're talking about implementing something we expect to be in the
> standard, I think we will have to live with what the standards committee
> decides, regardless of our prefe
On Jul 23, 2025, at 16:33, Bertrand Drouvot
wrote:
> Maybe we could use a flag, say:
>
> #define PGSTAT_PENDING_IO (1 << 0)
> #define PGSTAT_PENDING_WAL(1 << 1)
> #define PGSTAT_PENDING_SLRU (1 << 2)
>
> and check for a pgstat_pending_mask in pgstat_report_stat() instead?
>
> They wo
On Wednesday, July 23, 2025 12:08 PM Amit Kapila
wrote:
>
> On Wed, Jul 23, 2025 at 3:51 AM Masahiko Sawada
> wrote:
> >
> > I've reviewed the 0001 patch and it looks good to me.
> >
>
> Thanks, I have pushed the 0001 patch.
Thanks for pushing. I have rebased the remaining patches.
I have re
Hi,
On Wed, Jul 23, 2025 at 09:54:12AM +0900, Michael Paquier wrote:
> Then, about the loop used here, I'd be OK to keep the past shortcuts
> for the builtin fixed-sized stats kinds with the requirement that new
> builtin stats kinds need to hack into pgstat_report_stat() themselves
> on efficienc
Hi Ashutosh,
On Tue, Jul 22, 2025 at 8:40 PM Ashutosh Bapat
wrote:
> Here's the patchset rebased on the latest master.
Thanks for the update. I was going through the patch series today and
had a few comments on the structure that might help with reviewing and
eventually committing, whoever ends
On Wed, Jul 23, 2025 at 1:33 PM Jim Jones wrote:
>
> I believe that 'read/write' is more idiomatic than 'read-write' in this
> context. 'Read-only' works as a hyphenated adjective, and 'read/write'
> is typically treated as a paired label that indicates two distinct
> capabilities --- read and wr
On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita wrote:
> Another thing I noticed about transition tables is that while we
> prohibit transition tables on views/foreign tables, there is no
> description about that in the user-facing documentation. So I would
> like to propose to do $SUBJECT in creat
On 23.07.2025 03:11, David Rowley wrote:
On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov wrote:
The 'Buffers:' way looks more natural to me. I don't like duplicated
text in the explain format - it is already cluttered by multiple
unnecessary elements that distract attention from the problematic
Hi,
I try to configure these 3 parameters to activate keep alive on a sever
Postgres in version 14.
tcp_keepalives_idle = 3
tcp_keepalives_interval = 2
tcp_keepalives_count = 30
After issuing alter system set ... command and a pg_reload_conf(); these
parameters keep value 0.
I also check these
On Thu, Mar 6, 2025, at 17:43, Heikki Linnakangas wrote:
> On 06/03/2025 02:47, Heikki Linnakangas wrote:
>> Here's a new patch set. It includes the previous work, and also goes the
>> whole hog and replaces procsignals and many other signalling with
>> interrupts. It's based on Thomas's v3-0002-
Jeff Davis wrote:
> * The libc C.UTF-8 locale was a reasonable default (though not a
> natural language collation). But now that we have C.UTF-8 available
> from the builtin provider, then we should encourage that instead of
> relying on the slower, platform-specific libc implementation.
On Wed, Jul 23, 2025 at 4:32 PM Amit Kapila wrote:
>
> On Mon, Jul 21, 2025 at 6:59 PM Ajin Cherian wrote:
> >
> > Yes, this is correct. I have also verified this in my testing that
> > when there is a second subscription, a deadlock can still happen with
> > my previous patch. I have now modifie
On Tue, 22 Jul 2025 17:49:49 +0900
Yugo Nagata wrote:
> On Fri, 18 Jul 2025 17:07:53 +0900
> Rintaro Ikeda wrote:
>
> > Hi,
> >
> > On 2025/07/16 22:49, Yugo Nagata wrote:
> > >> I think we should also change the error message in pg_log_error. I
> > >> modified the
> > >> patch v8-0003 as fol
David Rowley writes:
> On Thu, 24 Jul 2025 at 12:27, Tom Lane wrote:
>> Hmmm ... but you did check that in fact we can remove such known-dead
>> code and not get a warning now?
> Yes. The patch has a small temporary adjustment to
> BaseBackupGetTargetHandle() to comment out the return. It compil
On Tue, Jul 22, 2025 at 8:49 PM David Rowley wrote:
> I don't think having a GUC which allows exactly two settings is
> anywhere near as flexible as you could make this.
I would phrase it as being a GUC with two settings currently,
I think it is easier to go from 2 possible algorithms to 3 than
(Moving this discussion to hackers. Previously in [0].)
Background:
The ereport_domain() macro has a pg_unreachable() which is meant to be
hit when the elevel >= ERROR so that the compiler can determine that
elog/ereport ERROR never returns. This works fine in gcc and clang but
MSVC seems to be u
On Wed, Jul 23, 2025 at 9:59 PM Peter Geoghegan wrote:
> Tomas' index-prefetch-simple-master branch:
> │ I/O Timings: shared read=1490.918
> │ Execution Time: 2015.731 ms
> Complex patch (same prewarming/eviction are omitted this time):
> │ I/O Timings: shared read=138.856
> │ Exe
Michael Paquier writes:
> Are you planning to look at that for the next minor release? It would
> take me a couple of hours to dig into all that, and I am sure that I
> am going to need your stamp or Erik's to avoid doing a stupid thing.
It was my commit, so my responsibility, so I'll deal with
On Wed, Jul 23, 2025 at 12:07:56PM +0800, Japin Li wrote:
> PFA to assert all required IndexAM callbacks are present.
@@ -42,6 +42,19 @@ GetIndexAmRoutine(Oid amhandler)
elog(ERROR, "index access method handler function %u did not return an
IndexAmRoutine struct",
amhandler
Hi Amit,
On Mon, Jul 14, 2025 at 3:31 PM Amit Kapila wrote:
>
> On Mon, Jul 14, 2025 at 10:55 AM Ashutosh Bapat
> wrote:
> >
> > On Sun, Jul 13, 2025 at 4:34 PM Amit Kapila wrote:
> > >
> > >
> > > I think we don't want to make it mandatory for plugins to implement
> > > these stats, so instead
Michael Paquier writes:
> A customer has reported a regression with the parsing of rather large
> XML data, introduced by the set of backpatches done with f68d6aabb7e2
> & friends.
Bleah.
> Switching back to the previous code, where we rely on
> xmlParseBalancedChunkMemory() fixes the issue.
Ye
On Wed, Jul 23, 2025 at 12:53 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Wednesday, July 23, 2025 12:08 PM Amit Kapila
> wrote:
> >
> > On Wed, Jul 23, 2025 at 3:51 AM Masahiko Sawada
> > wrote:
> > >
> > > I've reviewed the 0001 patch and it looks good to me.
> > >
> >
> > Thanks, I have pushed the
On Wed, Jul 23, 2025 at 5:11 PM Álvaro Herrera wrote:
> As a very trivial test on this patch, I ran the query in your opening
> email, both with and without the patch, scaling up the size of the table
> a little bit.
> This is a really nice improvement. I think we could find queries that
> are a
On Wed, Jul 23, 2025 at 11:28:38PM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> Switching back to the previous code, where we rely on
>> xmlParseBalancedChunkMemory() fixes the issue.
>
> Yeah, just reverting these commits might be an acceptable answer,
> since the main point was to work a
[ returning to this thread now that v19 is open for business ]
Robert Haas writes:
> I rediscovered, or re-encountered, this problem today, which motivated
> me to have a closer look at your (Tom's) patch. My feeling is that
> it's the right approach. I agree that we could try to keep the current
On Friday 2025-06-13 03:42, Greg Sabino Mullane wrote:
I think the overall idea is sound. But we need a better solution for the
truncate fk failure. Can we introspect somehow and do a truncate or do a delete
as necessary? I don't like the idea of simply ignoring the constraint, or of
throwin
Hi,
On 2025-07-23 19:59:52 +0200, Álvaro Herrera wrote:
> ... so using the same set of productions, I can rewrite the current
> CLUSTER rule in this way and it won't be a problem for the REPACK
> changes.
But it comes at the price of henceforth duplicating all ClusterStmt, once for
VERBOSE and on
On Thu, 24 Jul 2025 at 08:52, Greg Hennessy wrote:
> Adding a new enum to solve a perceived problem doesn't seem like a large
> ask to me.
Seems overly slow to me. As someone has to write the patch, a
committer has to commit said patch, the user must wait for the next
major version to be released
Hi Nathan, I've noticed you've set yourself as a reviewer of this patch
in the commitfest. I appreciate it, but you might want to combine it
with another simple patch [1] that speeds up the same part of
pg_restore: the initial full scan on TOC-less archives.
[1] https://commitfest.postgresql.o
On Tue, Jul 22, 2025 at 8:26 PM Vik Fearing wrote:
>
> The actual syntax is:
>
>
> ::=
> CAST
> AS
> [ FORMAT ]
> [ ON CONVERSION ERROR ]
>
>
>
> "CONVERSION" is probably a noise word, but it is there because A) Oracle
> wanted it there, and B) it ma
On Tue, Jul 22, 2025 at 6:50 PM David Rowley wrote:
> On Tue, 22 Jul 2025 at 05:16, Sami Imseih wrote:
> > Also, I'd like to ask. what would be the argument against offering both
> > options,
> > ALTER and a GUC to override the catalog, as currently proposed in the patch?
>
> For me, the reason
On Wed, Jul 23, 2025 at 12:36 PM Peter Geoghegan wrote:
> * The TPC-C order line table primary key.
I tested this for myself.
Tomas' index-prefetch-simple-master branch:
set max_parallel_workers_per_gather =0;
SELECT pg_buffercache_evict_relation('order_line');
select pg_prewarm('order_line_pke
On Fri, 2025-07-11 at 11:48 +1200, Thomas Munro wrote:
> On Fri, Jul 11, 2025 at 6:22 AM Jeff Davis wrote:
> > I don't have a great windows development environment, and it
> > appears CI
> > and the buildfarm don't offer great coverage either. Can I ask for
> > a
> > volunteer to do the windows si
On Tue, Jul 22, 2025 at 06:04:50PM -0500, Sami Imseih wrote:
> Regardless of what comes out of this thread, pg_hint_plan supporting
> a NoIndexScan hint that takes in an index name, and not only a relname
> is needed. I plan on taking that up there.
Patches are welcome upstream.
--
Michael
signa
On Thu, 24 Jul 2025 at 12:27, Tom Lane wrote:
> Hmmm ... but you did check that in fact we can remove such known-dead
> code and not get a warning now?
Yes. The patch has a small temporary adjustment to
BaseBackupGetTargetHandle() to comment out the return. It compiles for
me using Visual Studio
On Tue, Jul 22, 2025 at 01:15:16PM -0500, Sami Imseih wrote:
> The GUC serves multiple purposes. For example,I can create an index as
> invisible
> and use it in a controlled way, which is helpful for experimenting
> with a new index.
An in-core GUC to control the list of indexes that should be a
Hello Takatsuka-san,
23.07.2025 08:48, TAKATSUKA Haruka wrote:
Hello Alexander,
On Wed, 23 Jul 2025 00:55:37 +
Yugo Nagata - Buildfarm wrote:
Nagata-san, could you please share the configuration of hamerkop? If it's
running inside VM, what virtualization software is used?
It's vmware ESX
On Wed, 2025-07-23 at 13:53 +0200, Daniel Verite wrote:
> > * The libc C.UTF-8 locale was a reasonable default (though not a
> > natural language collation). But now that we have C.UTF-8 available
> > from the builtin provider, then we should encourage that instead of
> > relying on the slower, pla
On Wed, Jul 23, 2025 at 11:59:11AM -0400, Andres Freund wrote:
> On 2025-07-23 10:23:53 +, Bertrand Drouvot wrote:
>> Indeed, with a single boolean flag, then how could a stat say that it has
>> nothing
>> pending anymore (when flushing) without saying "all the stats have nothing
>> pending" (
David Rowley writes:
> I did a quick check of the postgres.exe size with and without this
> change. It does save about 13KB, but that seems to be entirely from
> the /std:c11 flag. None is due to the compiler emitting less code
> after elog(ERROR) / ereport(ERROR) :-(
Hmmm ... but you did check t
On Wed, Jul 23, 2025 at 12:00:55PM -0400, Andres Freund wrote:
> On 2025-07-23 09:54:12 +0900, Michael Paquier wrote:
>> Noted. I was wondering originally if the threshold for the builtin
>> and custom kinds should be lowered, as well. Perhaps that's just too
>> optimistic, so we can first lower
On Wed, 23 Jul 2025 23:00:00 +0300
Alexander Lakhin wrote:
{snip}
> >>> Nagata-san, could you please share the configuration of hamerkop? If it's
> >>> running inside VM, what virtualization software is used?
> > It's vmware ESXi 7.0.3 (21930508).
> > This Windows enable auto-synchronize with '
Hi all,
(Adding in CC Tom and Eric, as committer and author.)
A customer has reported a regression with the parsing of rather large
XML data, introduced by the set of backpatches done with f68d6aabb7e2
& friends.
The problem is introduced by the change from
xmlParseBalancedChunkMemory() to xmlNe
On 23/7/2025 02:11, David Rowley wrote:
> On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov wrote:
>> However, at first, I'd consider how it could be added to the
>> IncrementalSort and HashJoin. The number of estimated groups/buckets may
>> also provide some insights into the planner's decision.
>
>
Hi Jim,
On Tue, Jul 22, 2025 at 4:40 PM Jim Jones wrote:
> Hi
>
> On 21.07.25 21:12, Greg Sabino Mullane wrote:
> > Seems good enough for me. I think as long as we document it well, it's
> > only going to be a net positive, even with some edge cases.
>
> I just moved the patch from PG19-Drafts t
On Wed, Jul 23, 2025 at 05:04:37AM +, Hayato Kuroda (Fujitsu) wrote:
> While working on [1] I found the point. When recovery_target_lsn is specified
> and
> recovery_target_inclusive is false, recoveryStopsAfter() cannot return true.
>
> /* Check if the target LSN has been reached */
>
Hi Srinath
On 23.07.25 09:03, Srinath Reddy Sadipiralla wrote:
> +1 for the patch,i have reviewed and tested this patch, except these
> below cosmetic changes it LGTM.
>
> cosmetic changes:
> 1) add comment about %i in get_prompt api.
Done.
> 2) maybe we can use read-write instead of read/write
> Dear Ajin,
>
> Thanks for the patch. Firstly let me confirm my understanding. While altering
> the
> subscription, locks are acquired with below ordering:
>
I forgot to confirm one point. For which branch should be backpatch? Initially
it was reported only on PG15 [1], but I found 021_alter_su
On 7/23/25 03:31, Peter Geoghegan wrote:
> On Tue, Jul 22, 2025 at 8:37 PM Tomas Vondra wrote:
>>> I happen to think that that's a very unrealistic assumption. Most
>>> standard benchmarks have indexes that almost all look fairly similar
>>> to pgbench_accounts_pkey, from the point of view of "hea
85 matches
Mail list logo
