For a subquery relation, currently we consider pushing down its
restriction clauses to become WHERE or HAVING quals of the subquery
itself. This transformation can potentially avoid the need to
evaluate all subquery output rows before filtering them, which may
lead to a more efficient execution pl
On Sat, Jul 26, 2025 at 12:26:21AM +0900, Hironobu SUZUKI wrote:
> Even when using EXPLAIN ANALYZE with TIMING=FALSE, the functions
> InstrStopNode(), InstrEndLoop(), and InstrAggNode() in Instrument.c still
> execute code related to the "starttime", "counter", "firsttuple", "startup",
> and "total
Andrew Dunstan writes:
> Before we throw the baby out with the bathwater, how about this
> suggestion? pg_dumpall would continue to produce globals.dat, but it
> wouldn't be processed by pg_restore, which would only restore the
> individual databases. Or else we just don't produce globals.dat a
Etsuro Fujita writes:
> On Fri, May 30, 2025 at 2:02 AM Tom Lane wrote:
>> Finally, here's a minimalistic version of the original v1-0001
>> patch that I think we could safely apply to fix the DirectModify
>> problem in the back branches. I rejiggered it to not depend on
>> inventing MemoryConte
> Sami Imseih writes:
> >> Perhaps CachedPlanType is
> >> misnamed, though, would it be more suited to name that as a sort of
> >> "origin" or "source" field concept? We want to know which which
> >> source we have retrieved a plan that a PlannedStmt refers to.
>
> > Hmm, I’m not sure I see this
On 2025-07-25 Fr 12:21 PM, Noah Misch wrote:
On Thu, Jul 24, 2025 at 04:33:15PM -0400, Andrew Dunstan wrote:
On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
I suspect this is going to end with a structured dump like we use on the
pg_dump (per-database) side. It's not an accident that v17 pg_resto
On 7/22/25 14:43, Greg Burd wrote:
> On 7/21/25 14:35, Andres Freund wrote:
>> Hi,
>>
>> On 2025-07-21 13:37:04 -0400, Greg Burd wrote:
>>> On 7/18/25 13:03, Andres Freund wrote:
>>> Hello. Thanks again for taking the time to review the email and patch,
>>> I think we're onto something good here.
> On 21 Jul 2025, at 19:58, Andrey Borodin wrote:
>
> I'm planning to prepare tests and fixes for all supported branches
This is a status update message. I've reproduced problem on REL_13_STABLE and
verified that proposed fix works there.
Also I've discovered one more serious problem.
If a
Robert Treat writes:
> On Thu, Jul 24, 2025 at 8:08 PM Michael Paquier wrote:
>> If it were discussing things from the perspective where this new code
>> was added after a major version bump of Postgres, I would not argue
>> much about that: breakages happen every year and users adapt their
>> ap
Hi Jakub
On 7/24/25 10:01 AM, Jakub Wartak wrote:
On Tue, Jul 22, 2025 at 11:30 AM Patrick Stählin wrote:
Hi!
On 4/7/25 11:27 PM, Tomas Vondra wrote:
I've pushed all three parts of v29, with some additional corrections
(picked lower OIDs, bumped catversion, fixed commit messages).
While
On Thu, Jul 24, 2025 at 8:08 PM Michael Paquier wrote:
> On Fri, Jul 25, 2025 at 01:25:48AM +0200, Jim Jones wrote:
> > On 24.07.25 21:23, Tom Lane wrote:
> >> However, when testing on RHEL8 with libxml2 2.9.7, indeed
> >> I get "Huge input lookup" with our current code but no
> >> failure with f6
On Thu, Jul 24, 2025 at 10:27 PM Noah Misch wrote:
> I regret missing those in v1. I've attached v2, including branch-specific
> patches. I'll first need to back-patch 350e6b8, which fixed sorting of CREATE
> RULE, to v17 and earlier. Since 350e6b8 is conflict-free all the way back to
> v13, I'
On Mon, Jul 21, 2025 at 7:49 PM Andres Freund wrote:
> That is not to say you can't have callbacks or such, it just doesn't make
> sense for those callbacks to be at the level of tableam. If you want to make
> vacuumparallel support parallel table vacuuming for multiple table AMs (I'm
> somewhat d
On Fri, Jul 25, 2025 at 12:34 PM Nathan Bossart
wrote:
>
> On Fri, Jul 25, 2025 at 11:47:52AM -0300, Fabrízio de Royes Mello wrote:
> > Attached patch for $SUBJECT.
>
> Could we move this to the existing thread on the topic [0]? I see one
more
> CopyData character in this file, plus some others t
Sami Imseih writes:
>> Perhaps CachedPlanType is
>> misnamed, though, would it be more suited to name that as a sort of
>> "origin" or "source" field concept? We want to know which which
>> source we have retrieved a plan that a PlannedStmt refers to.
> Hmm, I’m not sure I see this as an improve
On 7/25/25 17:34, Paul A Jungwirth wrote:
> On Thu, Jul 24, 2025 at 12:09 PM Robert Haas wrote:
>> I think that the motivating use case for the existing support was
>> wanting to offload work to something that looks altogether unlike the
>> normal PostgreSQL executor, rather than (as you want t
On Thu, Jul 24, 2025 at 04:33:15PM -0400, Andrew Dunstan wrote:
> On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
> > I suspect this is going to end with a structured dump like we use on the
> > pg_dump (per-database) side. It's not an accident that v17 pg_restore
> > doesn't
> > lex text files to do
On Fri, Jul 25, 2025 at 3:23 PM Xuneng Zhou wrote:
>
> Thanks for reviewing and feedback!
>
> > The v8 is attached. It's basically the same as v6, but has revised
> > commit message and comments.
> >
> > The patch for stable branches is also attached: it just limits the
> > maximum size of the ch
On Thu, Jul 24, 2025 at 12:09 PM Robert Haas wrote:
> I think that the motivating use case for the existing support was
> wanting to offload work to something that looks altogether unlike the
> normal PostgreSQL executor, rather than (as you want to do) implement
> a new type of join within the Po
On Fri, Jul 25, 2025 at 11:47:52AM -0300, Fabrízio de Royes Mello wrote:
> Attached patch for $SUBJECT.
Could we move this to the existing thread on the topic [0]? I see one more
CopyData character in this file, plus some others that probably need their
own characters in protocol.h:
./basebackup
On Fri, Jul 25, 2025 at 10:53 PM cca5507 wrote:
>
> > For example, we could add a check like the following to
> > 013_crash_restart.pl.
> > Thoughts?
> >
> > -
> > is($node->safe_psql('postgres',
> > "SELECT count(*) = 1 FROM pg_stat_activity WHERE backend_type =
> > 'logical repl
> Perhaps CachedPlanType is
> misnamed, though, would it be more suited to name that as a sort of
> "origin" or "source" field concept? We want to know which which
> source we have retrieved a plan that a PlannedStmt refers to.
Hmm, I’m not sure I see this as an improvement. In my opinion,
Cached
Hi,
Even when using EXPLAIN ANALYZE with TIMING=FALSE, the functions
InstrStopNode(), InstrEndLoop(), and InstrAggNode() in Instrument.c
still execute code related to the "starttime", "counter", "firsttuple",
"startup", and "total" fields within the Instrumentation structure.
These operations
Aidar Imamov writes:
> Thank's, I agree with you.
> Attaching an edited version of the patch.
Re-reading this in the light of morning, I realized that it can be
done even more simply: let's just move isfixed to the shared struct,
rather than keep two copies. The argument for two copies of keysiz
On 25/07/2025 14:55, Matheus Alcantara wrote:
On Mon Jul 21, 2025 at 7:11 PM -03, Vik Fearing wrote:
SELECT a, b, c
FROM tab
QUALIFY wf() OVER () = ?
can be rewritten as:
SELECT a, b, c
FROM (
SELECT a, b, c, wf() OVER () = ? AS qc
FROM tab
) AS q
WHERE qc
and then let the op
Attached patch for $SUBJECT.
--
Fabrízio de Royes Mello
From 37a119f5c4c01dbf71efe32180e00b5fa0add517 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabr=C3=ADzio=20de=20Royes=20Mello?=
Date: Fri, 25 Jul 2025 11:45:48 -0300
Subject: [PATCH] Use PqMsg_* macros in basebackup_copy.c
---
src/backend/ba
On Thu, Jul 24, 2025 at 05:39:14PM -0400, Dave Cramer wrote:
> On Thu, 24 Jul 2025 at 17:05, Jacob Champion <
> jacob.champ...@enterprisedb.com> wrote:
>> Since these are part of the replication subprotocol (i.e. tunneled,
>> via CopyData) rather than the top-level wire protocol, do they deserve
>>
On Fri, Jul 25, 2025 at 06:28:28AM -0400, Dave Cramer wrote:
> On Fri, 25 Jul 2025 at 06:23, Álvaro Herrera wrote:
>> Yeah, we could rename it, as in the attached. It doesn't harm anything.
>
> Consistency is good. If your patch were applied, then it would be
> consistent to use WALData
+1
--
Hi,
On Jul 25, 2025 at 21:35 +0800, Tom Lane , wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
> > Reproducing a table might need multiple commands. Do you intend to
> > return a single string containing multiple semicolon-separated commands,
> > or are you thinking in a RETURNS SETOF where eac
On Fri, Jul 25, 2025 at 2:31 PM Amit Kapila wrote:
>
> On Fri, Jul 25, 2025 at 12:37 PM shveta malik wrote:
> >
> > On Thu, Jul 24, 2025 at 9:12 AM shveta malik wrote:
> > >
> > >
> > > 2)
> > > + if (MySubscription->retaindeadtuples &&
> > > + FindMostRecentl
> For example, we could add a check like the following to
013_crash_restart.pl.
> Thoughts?
>
> -
> is($node->safe_psql('postgres',
> "SELECT count(*) = 1 FROM pg_stat_activity WHERE backend_type =
> 'logical replication launcher'"),
> 't',
> 'logical replication launcher is runni
On 2025-07-24 20:24, Tom Lane wrote:
Aidar Imamov writes:
Recently, while working with hash tables in dynahash.c, I noticed
something weird.
When a hash table is already created in shared memory, and the another
process
calls hash_create attempting to attach to it, it seems like the
HASH_FIXED_
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> Reproducing a table might need multiple commands. Do you intend to
> return a single string containing multiple semicolon-separated commands,
> or are you thinking in a RETURNS SETOF where each row contains a single
> command?
In the same vein: would we
Hi,
On Thu, Jul 24, 2025 at 10:30:06PM +0800, Mircea Cadariu wrote:
> I tried v5 and it returns the expected results on my
> laptop, same as before.
Thanks for the review and testing.
>
> Just two further remarks for your consideration.
>
> > +
> > + number of OS memory page for th
On 2025-07-25 Fr 4:34 AM, Álvaro Herrera wrote:
On 2025-Jul-24, Andrew Dunstan wrote:
Obviously we already have some functions for things like views and
triggers, but most notably we don't have one for tables, something users
have long complained about. I have been trying to think of a reason
On Mon Jul 21, 2025 at 7:11 PM -03, Vik Fearing wrote:
> That is my preferred grammar, thank you. I have not looked at the C
> code by this can be obtained with a syntax transformation. To wit:
>
>
> SELECT a, b, c
> FROM tab
> QUALIFY wf() OVER () = ?
>
>
> can be rewritten as:
>
>
> SELECT a, b
Hi, Alexander
Thanks for reviewing and feedback!
> The v8 is attached. It's basically the same as v6, but has revised
> commit message and comments.
>
> The patch for stable branches is also attached: it just limits the
> maximum size of the checkpointer requests queue.
LGTM.
Best,
Xuneng
On Tue, Jul 22, 2025 at 7:31 PM Andrei Lepikhov wrote:
>
> On 18/7/2025 13:48, Ashutosh Bapat wrote:
> > On Mon, Jul 7, 2025 at 8:43 PM Andrei Lepikhov wrote:
> > if (!IsA(new_path, IndexPath))
> > - pfree(new_path);
> > + free_path(new_path, 0, false);
> >
> > Why don't we free the subpaths if t
Hi All,
We conducted performance testing of a bi-directional logical
replication setup, focusing on the primary use case of the
update_deleted feature.
To simulate a realistic scenario, we used a high workload with limited
concurrent updates, and well-distributed writes among servers.
Used source
On Friday, July 25, 2025 2:33 PM Amit Kapila wrote:
>
> On Wed, Jul 23, 2025 at 12:53 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > Thanks for pushing. I have rebased the remaining patches.
> >
>
> + * This function performs a full table scan instead of using indexes
> + because
> + * index scans co
On Thursday, July 24, 2025 11:42 AM shveta malik wrote:
>
> 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 th
On Fri, Jul 25, 2025 at 3:22 PM Etsuro Fujita wrote:
>
> Hi Ashutosh,
>
> On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
> wrote:
> > 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 abou
On Tue, Jun 10, 2025 at 7:50 PM Naga Appani wrote:
>
> On Tue, Mar 11, 2025 at 4:48 AM Kirill Reshke wrote:
> >
> > On Tue, 11 Mar 2025 at 14:37, Naga Appani wrote:
> > >
> > >
> > >
> > > On Mon, Mar 10, 2025 at 10:43 AM Naga Appani wrote:
> > >>
> > >> Hi,
> > >>
> >
> > Hi
> >
> > >
On 7/25/25 12:27, Jakub Wartak wrote:
> On Thu, Jul 17, 2025 at 11:15 PM Tomas Vondra wrote:
>>
>> On 7/4/25 20:12, Tomas Vondra wrote:
>>> On 7/4/25 13:05, Jakub Wartak wrote:
...
8. v1-0005 2x + /* if (numa_procs_interleave) */
Ha! it's a TRAP! I've uncommented it
On Wed, Jun 18, 2025 at 10:43 AM David G. Johnston
wrote:
>
> On Tue, Jun 17, 2025 at 9:22 PM Amit Kapila wrote:
>>
>>
>> As shown in Vignesh's email [1] (point 4), there could be multiple
>> additional parameters required for the first option suggested by you,
>> which will make it longer. Addit
On Fri, 25 Jul 2025 at 06:23, Álvaro Herrera wrote:
> On 2025-Jul-25, Dave Cramer wrote:
>
> > FYI, the reason I used XLogData is because the term is used multiple
> times
> > here https://www.postgresql.org/docs/devel/protocol-replication.html
>
> Yeah, we could rename it, as in the attached. I
On Thu, Jul 17, 2025 at 11:15 PM Tomas Vondra wrote:
>
> On 7/4/25 20:12, Tomas Vondra wrote:
> > On 7/4/25 13:05, Jakub Wartak wrote:
> >> ...
> >>
> >> 8. v1-0005 2x + /* if (numa_procs_interleave) */
> >>
> >>Ha! it's a TRAP! I've uncommented it because I wanted to try it out
> >> without i
On 2025-Jul-24, Nathan Bossart wrote:
> On Thu, Jul 24, 2025 at 11:54:10AM +0200, Álvaro Herrera wrote:
> > Yeah, thanks for taking a look. That duplication is just me being dumb.
> > Here's a version without that. The only thing that needed to change was
> > changing "CLUSTER opt_verbose" to "C
On 2025-Jul-25, Dave Cramer wrote:
> FYI, the reason I used XLogData is because the term is used multiple times
> here https://www.postgresql.org/docs/devel/protocol-replication.html
Yeah, we could rename it, as in the attached. It doesn't harm anything.
--
Álvaro HerreraBreisgau, Deut
Hi Ashutosh,
On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
wrote:
> 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 vie
On Fri, Jul 25, 2025 at 5:25 PM shveta malik wrote:
>
> On Fri, Jul 25, 2025 at 7:17 AM Fujii Masao wrote:
> >
> > On Thu, Jul 24, 2025 at 6:46 PM shveta malik wrote:
> > > Sounds reasonable.
> > > Thinking out loud, when cleaning up after a backend or background
> > > worker crash, process_pm_c
Dave Cramer
On Fri, 25 Jul 2025 at 04:11, Álvaro Herrera wrote:
> On 2025-Jul-24, Dave Cramer wrote:
>
> > On Thu, 24 Jul 2025 at 17:05, Jacob Champion <
> > jacob.champ...@enterprisedb.com> wrote:
> >
> > > On Thu, Jul 24, 2025 at 12:04 PM Dave Cramer
> wrote:
>
> > > +/* Replication Protocol
On Fri, Jul 25, 2025 at 12:37 PM shveta malik wrote:
>
> On Thu, Jul 24, 2025 at 9:12 AM shveta malik wrote:
> >
> >
> > 2)
> > + if (MySubscription->retaindeadtuples &&
> > + FindMostRecentlyDeletedTupleInfo(localrel,
> > remoteslot,
> > +
> >
Hi,
On Fri, Jul 25, 2025 at 10:38:59AM +0900, Michael Paquier wrote:
> On Thu, Jul 24, 2025 at 07:38:46AM +, Bertrand Drouvot wrote:
> > What about?
> >
> > - create a global variable but that should be used only by extensions? Say,
> > pgstat_report_custom_fixed
> >
> > - for builtin fixed-
A related improvement would be to also support
CREATE EXTENSION psql;
To make at least the `\d ...` commands available to any client
And while we are at it, why not also
CREATE EXTENSION pgbench;
To make the fancy random distribution functions (at least) from
pgbench available from inside the
On Thu, 24 Jul 2025 at 17:45, Ajin Cherian wrote:
>
> On Wed, Jul 23, 2025 at 8:01 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 orderi
I have been thinking of this from a little different direction. We
already have all the needed functionality in pg_dump so why not just
have an option to do
CREATE EXTENSION pg_dump;
Which would wrap and expose whatever the current version of pg_dump is doing.
It still would need to resolve the
Rebased version attached, following 904f6a593a0.
Regards,
Dean
From a47423cc29abc8dc197fb895b55aace66d9da885 Mon Sep 17 00:00:00 2001
From: Dean Rasheed
Date: Fri, 25 Jul 2025 08:57:03 +0100
Subject: [PATCH v4] Allow EXCLUDED in RETURNING list of INSERT ON CONFLICT DO
UPDATE.
This allows an INS
On 2025-Jul-24, Andrew Dunstan wrote:
> Obviously we already have some functions for things like views and
> triggers, but most notably we don't have one for tables, something users
> have long complained about. I have been trying to think of a reasonable
> interface for a single function, where w
On Fri, Jul 25, 2025 at 7:17 AM Fujii Masao wrote:
>
> On Thu, Jul 24, 2025 at 6:46 PM shveta malik wrote:
> > Sounds reasonable.
> > Thinking out loud, when cleaning up after a backend or background
> > worker crash, process_pm_child_exit() is invoked, which subsequently
> > calls both CleanupBa
On 2025-Jul-24, Dave Cramer wrote:
> On Thu, 24 Jul 2025 at 17:05, Jacob Champion <
> jacob.champ...@enterprisedb.com> wrote:
>
> > On Thu, Jul 24, 2025 at 12:04 PM Dave Cramer wrote:
> > +/* Replication Protocol sent by the primary */
> > +
> > +#define PqMsg_XlogData 'w'
> > +#de
Thank you for your reply, Robert.
My main goal was to report this observation, because I was surprised to see
that in the dump the grantors were not exported.
Thanks for drawing my attention to the "observes" section; it is indeed
very useful.
For my part, I corrected the problem related to this pe
Dear Ajin,
Thanks for patches! While checking, I recalled that the backpatch policy [1].
We must not modify definitions of opened functions but this does. Can you define
another function like UpdateSubscriptionRelStateEx or something on the back
branches?
Another comment:
```
@@ -328,9 +328,13 @@
Attached are the v17 patches for adding RESPECT/IGNORE NULLS options
defined in the standard to some window functions. FROM FIRST/LAST
options are not considered in the patch (yet).
This time I split the patch into 6
patches for reviewer's convenience. Also each patch has a short commit
message to
On fri. 25 jul. 2025, 00:01, Jacob Champion <
jacob.champ...@enterprisedb.com> wrote :
>
> > If you agree, we can suggest a patch for the documentation.
>
> If you've tripped over it, I think we should consider a docs patch.
>
We've spent time on it, guessing it was a return code-driven behaviou
On Thu, Jul 24, 2025 at 9:12 AM shveta malik wrote:
>
>
> 2)
> + if (MySubscription->retaindeadtuples &&
> + FindMostRecentlyDeletedTupleInfo(localrel, remoteslot,
> +
> &conflicttuple.xmin,
> +
> &conflicttuple.origin,
> +
>
66 matches
Mail list logo
