On Sat, 19 Jul 2025 at 01:39, Álvaro Herrera wrote:
>
> On 2025-Jul-18, vignesh C wrote:
>
> > diff --git a/contrib/postgres_fdw/connection.c
> > b/contrib/postgres_fdw/connection.c
> > index 304f3c20f83..c1ce6f33436 100644
> > --- a/contrib/postgres_fdw/connection.c
> > +++ b/contrib/postgres_fd
On Fri, Jul 18, 2025 at 11:57:07AM +0300, Nazir Bilal Yavuz wrote:
> I added that as 0001. I used a shifting method for the 'tail'
> direction to not use too much memory. I found that there is
> 'File::ReadBackwards' in Perl but you need to install it, so I didn't
> use it.
Some old buildfarm may
Hi,
On Jul 18, 2025 at 22:52 +0800, feichanghong , wrote:
>
> explain select * from (select * from t where a = 1 and b > 1 order by a, b)
> order by a, b limit 1;
> QUERY PLAN
>
On Fri, Jul 18, 2025 at 10:24:12PM +0300, Nikita Malakhov wrote:
> I'm currently debugging POC direct tids TOAST patch (on top of your branch),
> will mail it in a day or two.
Interesting. Of course I may be wrong because I have no idea of how
you have shaped things, still I suspect that for the
On Sat, Jul 19, 2025 at 3:01 AM Masahiko Sawada wrote:
>
> On Fri, Jul 18, 2025 at 5:03 AM Zhijie Hou (Fujitsu)
> wrote:
> >
>
> Here are some review comments and questions:
>
>
> ---
> + if (inCommitOnly &&
> + (proc->delayChkptFlags & DELAY_CHKPT_IN_COMMIT) == 0)
> + c
Hi
so 19. 7. 2025 v 5:08 odesílatel Tom Lane napsal:
> "David G. Johnston" writes:
> > On Sunday, July 6, 2025, Paul Jungwirth
> wrote:
> >> The second patch adds a new explaining how we inline SQL
> >> functions: both single-result and set-returning. Since this happens
> >> automatically, it
On Sat, Jul 19, 2025 at 6:31 AM Tomas Vondra wrote:
> Perhaps the ReadStream should do something like this? Of course, the
> simple patch resets the stream very often, likely mcuh more often than
> anything else in the code. But wouldn't it be beneficial for streams
> reset because of a rescan? Po
On Friday, July 18, 2025, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Sunday, July 6, 2025, Paul Jungwirth
> wrote:
> >> The second patch adds a new explaining how we inline SQL
> >> functions: both single-result and set-returning. Since this happens
> >> automatically, it makes a nic
> On Jul 18, 2025, at 22:37, feichanghong wrote:
>
> Should we retain the complete `pathkeys` in `Path->pathkeys` for use by the
> upper layers of the subquery, rather than just keeping the portion trimmed by
> `PlannerInfo->query_pathkeys`? I'm not sure if my understanding is correct.
Currentl
On Fri, Jul 18, 2025 at 10:47 PM Andres Freund wrote:
> > I think that the table AM probably needs to have its own definition of
> > a batch (or some other distinct phrase/concept) -- it's not
> > necessarily the same group of TIDs that are associated with a batch on
> > the index AM side.
>
> I a
"David G. Johnston" writes:
> On Sunday, July 6, 2025, Paul Jungwirth wrote:
>> The second patch adds a new explaining how we inline SQL
>> functions: both single-result and set-returning. Since this happens
>> automatically, it makes a nice progression with the (easy) declarative
>> annotations
On Sunday, July 6, 2025, Paul Jungwirth wrote:
>
> The second patch adds a new explaining how we inline SQL
> functions: both single-result and set-returning. Since this happens
> automatically, it makes a nice progression with the (easy) declarative
> annotations and the (hard) support functions
Hi,
On 2025-07-18 17:44:26 -0400, Peter Geoghegan wrote:
> On Fri, Jul 18, 2025 at 4:52 PM Andres Freund wrote:
> > I don't agree with that. For efficiency reasons alone table AMs should get a
> > whole batch of TIDs at once. If you have an ordered indexscan that returns
> > TIDs that are correla
On Friday, July 18, 2025, Maciek Sakrejda wrote:
> +1, I think this is very nice to have. I knew about inlining, but not
> the details of the mechanism, so it's nice to see when I should expect
> it to happen.
+1 as well.
>
> I have some minor wording feedback:
>
> + And if an extension has h
On Thu, Jul 17, 2025 at 1:39 PM Melanie Plageman
wrote:
>
> On Mon, Jun 30, 2025 at 9:41 AM Masahiko Sawada wrote:
> >
> > I've rebased the patches to the current HEAD.
>
> Hi Sawada-san,
>
> I've started reviewing this. I initially meant to review the eager
> scan part, but I think it would be e
+1, I think this is very nice to have. I knew about inlining, but not
the details of the mechanism, so it's nice to see when I should expect
it to happen.
I have some minor wording feedback:
+ And if an extension has hooked function entry/exit,
+ then inlining must be skipped.
Maybe "And if any
On Fri, Jul 18, 2025 at 3:29 PM Daniel Gustafsson wrote:
> Ugh, In preparing for going on vacation this fell off the radar. I'll try to
> get to looking at it tomorrow during downtime unless beaten to it.
Your earlier mail made me worried I'd missed something, but is the
attached diff what Andre
On Fri, Jul 18, 2025 at 3:29 AM Dean Rasheed wrote:
> I agree that additional testing in this area is valuable. Patch 0001
> looks reasonable to me, on a quick read-through. In patch 0002, I
> think it would be valuable to also test updating the parent row to
> time periods consistent and not cons
On Mon, Jul 14, 2025 at 8:15 AM Nikita Malakhov wrote:
>
...
> Have to mention though that we encountered issues in logical replication
> when we made toast values updatable.
This seems to indicate that Logical Decoding does not honour
visibility checks in TOAST.
This works fine if the TOAST visi
> On 18 Jul 2025, at 19:26, Andres Freund wrote:
>> Hm, what problem did you encounter? I don't think there should be any
>> difficulty?
>
> Ping?
Ugh, In preparing for going on vacation this fell off the radar. I'll try to
get to looking at it tomorrow during downtime unless beaten to it.
--
On Fri, Jul 18, 2025 at 9:24 PM Nikita Malakhov wrote:
>
> Hi Michael,
>
> I'm currently debugging POC direct tids TOAST patch (on top of your branch),
> will mail it in a day or two.
Great!
I also just started looking at it, starting from 0003 as recommended by Michael.
Will be interesting to
On Fri, Jul 18, 2025 at 4:52 PM Andres Freund wrote:
> I don't agree with that. For efficiency reasons alone table AMs should get a
> whole batch of TIDs at once. If you have an ordered indexscan that returns
> TIDs that are correlated with the table, we waste *tremendous* amount of
> cycles right
On Fri, Jul 18, 2025 at 5:03 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, July 18, 2025 1:25 AM Masahiko Sawada
> wrote:
> >
> > On Fri, Jul 11, 2025 at 3:58 AM Amit Kapila wrote:
> > >
> > > On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada
> > wrote:
> > > >
> > > > On Wed, Jul 9, 2025 at 9:0
On Fri, Jul 18, 2025 at 12:55 PM Andres Freund wrote:
>
> Hi,
I think we're talking past each other, so let me try to focus on just
a few items here. I'm happy to go back and respond point-by-point if
needed.
> I don't know your fix really looks like - afaict you haven't shared it. So
> it's har
On Mon, Jul 7, 2025 at 3:31 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Mon, Jul 7, 2025 at 10:13 AM Zhijie Hou (Fujitsu) wrote:
> >
> > On Sun, Jul 6, 2025 at 10:51 PM Masahiko Sawada wrote:
> > >
> > > On Fri, Jul 4, 2025 at 8:18 PM Zhijie Hou (Fujitsu)
> > >
> > > wrote:
> > > >
> > > > On Wed, Jul
Hi,
On 2025-07-18 22:48:00 +0200, Tomas Vondra wrote:
> On 7/18/25 18:46, Andres Freund wrote:
> >> For a read-write pgbench I however saw some strange drops/increases of
> >> throughput. I suspect this might be due to some thinko in the clocksweep
> >> partitioning, but I'll need to take a closer
Hi,
On 2025-07-18 19:44:51 +0200, Tomas Vondra wrote:
> I agree tableam needs to have a say in this, so that it can interpret
> the TIDs in a way that fits how it actually stores data. But I'm not
> sure it should be responsible for calling index_batch_getnext(). Isn't
> the batching mostly an "im
I wrote:
> I'm inclined to accept 0001, reject 0002, and move on. This doesn't
> seem like an area that's worth a huge amount of discussion.
Done that way. I made a couple more cosmetic changes and added
test cases for the double-backslash code path (which hadn't been
covered in byteaout either,
On 7/18/25 18:46, Andres Freund wrote:
> Hi,
>
> On 2025-07-17 23:11:16 +0200, Tomas Vondra wrote:
>> Here's a v2 of the patch series, with a couple changes:
>
> Not a deep look at the code, just a quick reply.
>
>
>> * I changed the freelist partitioning scheme a little bit, based on the
>> di
On 2025-Jul-18, vignesh C wrote:
> diff --git a/contrib/postgres_fdw/connection.c
> b/contrib/postgres_fdw/connection.c
> index 304f3c20f83..c1ce6f33436 100644
> --- a/contrib/postgres_fdw/connection.c
> +++ b/contrib/postgres_fdw/connection.c
> @@ -625,6 +625,9 @@ connect_pg_server(ForeignServer
Hi,
On 2025-07-17 09:48:29 -0700, Jacob Champion wrote:
> On Wed, Jul 16, 2025 at 4:35 PM Andres Freund wrote:
> > Why do we care about not hitting the socket? We always operate the socket in
> > non-blocking mode anyway?
>
> IIUC, that would change pqReadData() from a bounded read to an
> unbou
Hi
po 7. 7. 2025 v 5:12 odesílatel Paul Jungwirth
napsal:
> Hi Hackers,
>
> Here are some documentation patches about inlining SQL-language functions.
> Postgres has been able to
> inline both scalar and set-returning functions since the 9.x days (as long
> as they are LANGUAGE SQL
> and meet a
> Hmm, I don't propose modifying costs. The focus is on resetting the plan
> cache decision that PostgreSQL has made in automatic mode. During the
> DBMS operation, various factors may cause a generic plan to be
> suboptimal or make it more desirable as well. Discussions from 2010 to
> 2013 indicat
Hi Michael,
I'm currently debugging POC direct tids TOAST patch (on top of your branch),
will mail it in a day or two.
On Tue, Jul 15, 2025 at 3:56 AM Michael Paquier wrote:
> On Mon, Jul 14, 2025 at 09:01:28AM +0300, Nikita Malakhov wrote:
> > Cool, toast tables are subject to bloating in upda
On Thu, Jul 17, 2025 at 09:24:02AM -0400, Robert Haas wrote:
> On Mon, Jul 7, 2025 at 3:27 PM Noah Misch wrote:
> > Let's get rid of pg_dump's need to sort by OID, apart from catalog
> > corruption
> > scenarios.
>
> +1. I had at one point believed that sorting by OID was a good way to
> make du
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
wrote:
> The current behavior for GSS is, IMO, an
> obvious oversight.
(A better way to word this would have been "clearly an oversight"; I
didn't mean to imply that the correct behavior is obvious. The
opposite, in fact.)
--Jacob
On Fri, Jul 18, 2025 at 1:44 PM Tomas Vondra wrote:
> I agree tableam needs to have a say in this, so that it can interpret
> the TIDs in a way that fits how it actually stores data. But I'm not
> sure it should be responsible for calling index_batch_getnext(). Isn't
> the batching mostly an "impl
Hi,
I was wondering why the "simple" approach performs so much worse than
the "complex" one on some of the data sets. The theory was that it's due
to using read_stream_reset(), which resets the prefetch distance, and so
we need to "ramp up" from scratch (distance=1) for every batch. Which
for the
On Wed, Jul 16, 2025 at 11:50 AM Jacob Champion
wrote:
> On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> > Do you have a WIP patch?
>
> I'm working on one now.
The attached still needs some documentation work, and closer
inspection of the new assertions and OpenSSL error handling, but I
On 7/17/25 00:33, Peter Geoghegan wrote:
> On Wed, Jul 16, 2025 at 6:18 PM Andres Freund wrote:
>> There's no problem today - the indexams never use the tids to look up blocks
>> themselves. They're always passed to the tableam to do so (via
>> table_index_fetch_tuple() etc). I.e. the translation
Hi,
On 2025-06-30 19:42:51 -0400, Andres Freund wrote:
> On 2025-07-01 00:52:49 +0200, Daniel Gustafsson wrote:
> > > On 30 Jun 2025, at 20:33, Jacob Champion
> > > wrote:
> > >
> > > On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson
> > > wrote:
> > >>> On 30 Jun 2025, at 18:58, Andres Freu
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 generates a *lot* of warnings here when building for 32 bit
> with
"Joel Jacobson" writes:
> My patch improves NOTIFY TPS when many backends are listening on multiple
> channels by eliminating unnecessary syscall wake‑ups, but it doesn't increase
> the internal parallelism of the NOTIFY queue itself.
After thinking about this for awhile, I have a rough idea of
s
On Fri, 18 Jul 2025 at 04:46, Fujii Masao wrote:
>
>
>
> On 2025/07/18 1:15, Álvaro Herrera wrote:
> > On 2025-Jul-18, Fujii Masao wrote:
> >
> >> The current patches add nearly identical notice_receiver functions
> >> in multiple places such as libpqwalreceiver.c and elsewhere. To avoid
> >> dupl
Hi,
I'd be curious if anybody wants to argue for keeping the clock sweep. Except
for the have_free_buffer() use in autoprewarm, it's a rather trivial
patch. And I really couldn't measure regressions above the noise level, even
if absurdly extreme use cases.
On 2025-07-17 14:35:13 -0400, Greg Bur
Hi,
On 2025-07-17 23:11:16 +0200, Tomas Vondra wrote:
> Here's a v2 of the patch series, with a couple changes:
Not a deep look at the code, just a quick reply.
> * I changed the freelist partitioning scheme a little bit, based on the
> discussion in this thread. Instead of having a single "par
On Fri, Jul 18, 2025 at 01:39:15PM +, Bertrand Drouvot wrote:
> 0002 - While doing changes in generate-lwlocknames.pl, I noticed that
> $continue is not used (Oversight in commit da952b415f4), so let's remove it.
I haven't looked closely at the other patches, but I went ahead and
committed th
Hi,
On 2025-07-17 20:09:57 -0400, Tom Lane wrote:
> In a discussion on Discord (in the PG #core-hacking channel,
> which unfortunately is inaccessible to non-members), Andres
> and Robert complained about the development/maintenance costs
> of continuing to support 32-bit platforms. Here is a mod
Committed.
I'm cautiously optimistic that we can find some better gains for upgrades
from v16 and newer. That would involve dumping lo_create() commands for
all LOs with comments/seclabels, dumping the relevant pg_shdepend rows, and
then copying/linking the pg_largeobject_metadata files like we d
Hi all,
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 submitted to the
commitfest has been flagged as "returned with feedback"
On Fri, Jul 18, 2025, at 10:15, Joel Jacobson wrote:
> On Fri, Jul 18, 2025, at 02:49, Rishu Bagga wrote:
>> Hi all,
>>
>> There’s been some renewed attention on improving the performance of the
>> LISTEN/NOTIFY system, which historically hasn’t scaled well under high
>> notify frequency. Joel Jaco
> Unless someone is willing to try and get “The PostgreSQL team’s blessed guide
> to index management”
> into the documentation
I really doubt we can agree on one set of index management guidelines.
If anything, this thread has proven there are many ways to bake this
cake :) and all approaches h
Hi,
On 2025-07-18 06:04:38 +, Bertrand Drouvot wrote:
> Here what I’ve done:
>
> 1. Added 2 probes: one in pgstat_report_wait_start() and one in
> pgstat_report_wait_end()
> to measure the wait events duration. Then, I ran make check-world and computed
> the duration percentiles (in microseco
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:
>> > > Alexander Korotkov писал(а) 2025-06-04 14:29:
>> > > > On W
Hi,
Recently, I found while using `union all order by limit` that `MergeAppend`
adds a `Sort` node even when child node data is already ordered, leading to
low execution efficiency.
The issue can be reproduced with the following case (on the latest master
branch). In the execution plan below, alt
On Fri, Jul 18, 2025 at 5:11 AM Álvaro Herrera wrote:
>
> Anyway, here's a patch.
>
one minor issue in getDomainConstraints:
for (int i = 0, j = 0; i < ntups; i++)
{
charcontype = (PQgetvalue(res, i, i_contype))[0];
constraint->contype = *(PQgetvalue(res, i,
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:
> > > Alexander Korotkov писал(а) 2025-06-04 14:29:
> > > > On Wed, Jan 29, 2025 at 11:59 AM Maxim Orlov
> wrote:
> > > >>
> >
"Michael J. Baars" writes:
> I receive data from a data provider on a daily basis, and noticed how they
> use fixed type floating point in text mode, to transmit data. As you might
> know, this type of transmission is not lossless.
It is if you use enough decimal digits. Are you sure you're not
"Michael J. Baars" writes:
> Somewhere in between release 16.3 and
> release 16.9, changes must have been implemented that make the execution
> engine about two times slower than it was.
That seems quite unlikely, and you've surely provided no details that
would help identify any such problem. M
> On 18 Jul 2025, at 16:53, Álvaro Herrera wrote:
>
> Hello,
>
> Andrey and I discussed this on IM, and after some back and forth, he
> came up with a brilliant idea: modify the WAL record for multixact
> creation, so that the offset of the next multixact is transmitted and
> can be replayed.
Hi Michael,
Thanks for all your great feedback.
> Or you could keep the "lineno" and the error generated in memory.c as
> this gives enough details about the location where the problem
> happens. We are going to need the extra "alloc_failed".
>
> [...]
>
> Hmm. But both are related and the same
Hi,
On Thu, Jul 17, 2025 at 02:25:46PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Jul 17, 2025 at 09:50:12AM +0900, Michael Paquier wrote:
> > On Wed, Jul 16, 2025 at 11:41:09AM +, Bertrand Drouvot wrote:
> >
> > > As a way to prevent this to occur we might want to add extra input file
Hi hackers,
Some discrepancies between wait_event_names.txt and predefined LWLocks tranches
have been observed, see: a493e741d32 ,08b9b9e043b and c3623703f36.
To prevent new discrepancies from occurring, this patch series aims to $SUBJECT
(as 5b1b9bce844 did for predefined LWLocks).
The patch se
Hi Michael,
On Fri, Jul 18, 2025 at 3:01 PM Michael J. Baars
wrote:
>
> Hello fellow PostgreSQL users and developers,
>
> I installed a new Fedora release last week and ran into a peculiar problem:
>
> Each night I need to run computations through about 70.000 rows and using
> release 16.3 that
Hello,
Andrey and I discussed this on IM, and after some back and forth, he
came up with a brilliant idea: modify the WAL record for multixact
creation, so that the offset of the next multixact is transmitted and
can be replayed. (We know it when we create each multixact, because the
number of me
On Mon, Jul 7, 2025 at 8:43 PM Andrei Lepikhov wrote:
>
> On 27/6/2025 12:01, Andrei Lepikhov wrote:
> > On 6/2/2024 13:51, Ashutosh Bapat wrote:
> >> On Fri, Dec 15, 2023 at 5:22 AM Ashutosh Bapat
> >> wrote:
> >> First patch is no longer required. Here's rebased set
> >>
> >> The patches are ra
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 is
> > > to add code comments for
Hackers,
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 Kuroda proposed a patch [5], which improves
comments by describing this behavior. As p
Ok, now that we have seemingly stabilized the VS 2019 upgrade, here is
the next patch set to actually raise the compiler requirement to C11.
Viewed from very far away, this just adjusts the existing places that
say C99 and replaces them with a C11 analogue.
The details are a bit of a longer s
On Thu, 2025-07-18 at 00:21, Laurenz Albe
发件人：David G. Johnston
On Thu, Jul 17, 2025 at 4:44 PM shveta malik wrote:
>
> On Thu, Jul 17, 2025 at 9:56 AM Dilip Kumar wrote:
> >
> > On Fri, Jul 11, 2025 at 4:28 PM Amit Kapila wrote:
> > >
> > > On Thu, Jul 10, 2025 at 6:46 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Wed, Jul 9, 2025 at 9:09 PM Amit Kap
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 is
> > to add code comments for avoiding the same mistake again described here:
> >
> > > Sounds re
On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
>
> The attached v20250717 version patch has the changes for the same.
>
Few comments on 0001 and 0002:
0001
1. Instead of introducing a new function, can we think of extending
the existing function pg_get_sequence_data()?
0002
2.
postgres=# Creat
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 is
> to add code comments for avoiding the same mistake again described here:
>
> > Sounds reasonable. As per analysis till now, it seems removal of new
> > assert is
On Wed, Jul 2, 2025 at 8:20 PM vignesh C wrote:
> On Sun, 29 Jun 2025 at 11:52, Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear hackers,
> >
> > Thanks everyone who are working on the bug. IIUC the remained task is
> > to add code comments for avoiding the same mistake again described here:
> >
> >
On 2025-Jul-17, Andrey Borodin wrote:
> Thinking more about the problem I see 3 ways to deal with this deadlock:
> 1. We check for recovery conflict even in presence of
> InterruptHoldoffCount. That's what patch v4 does.
> 2. Teach page_collect_tuples() to do HeapTupleSatisfiesVisibility()
> witho
On Fri, 11 Jul 2025 at 23:22, Paul Jungwirth
wrote:
>
> On 7/11/25 11:50, Rustam ALLAKOV wrote:
> > Hi Paul,
> > Thanks for this patch!
> > Lilian and I have reviewed your patches.
>
> Thank you for the review! I've attached new patches addressing your feedback.
>
I agree that additional testing
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 17 Jul 2025 13:44:11 -0700,
Masahiko Sawada wrote:
>> > How about adding accessors instead of splitting
>> > Copy{From,To}State to Copy{From,To}ExecutionData? If we use
>> > the accessors approach, we
On Fri, Jul 18, 2025, at 08:46, Joel Jacobson wrote:
> However, for cases when up to K backends listen on the same channel
> (multicast),
> my patch and benchmark in the other thread suggests we can achieve massive
> improvements of parallelization of both LISTEN/UNLISTEN as well as NOTIFY
> witho
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 17 Jul 2025 13:33:13 -0700,
Masahiko Sawada wrote:
>> I've not followed the development of this patch - but I continue to be
>> concerned about the performance impact it has as-is and the amount of COP
On 17/7/2025 20:19, Sami Imseih wrote:
Thanks for the clarification. I see what you're getting at now.
Thanks for reading this!
You're suggesting adding CachedPlanSource to QueryDesc instead of
CachedPlan. This would allow extensions to access the statistics and cost
information from the Cache
On Fri, Jul 18, 2025 at 2:27 PM shveta malik wrote:
>
> On Thu, Jul 17, 2025 at 3:06 PM Amit Kapila wrote:
> >
> > On Wed, Jun 18, 2025 at 3:23 PM shveta malik wrote:
> > >
> > > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Tue, Jun 10, 20
Hello fellow PostgreSQL users and developers,
I installed a new Fedora release last week and ran into a peculiar problem:
Each night I need to run computations through about 70.000 rows and using
release 16.3 that took about 4 hours to complete, but using release 16.9
the same computations now ta
On Thu, Jul 17, 2025 at 3:06 PM Amit Kapila wrote:
>
> On Wed, Jun 18, 2025 at 3:23 PM shveta malik wrote:
> >
> > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jun 10, 2025 at 02:00:55PM -0700, Masahiko Sawada wrote:
> > > > > > > > > 0001 patch
Hi,
On Thu, 17 Jul 2025 at 03:08, Michael Paquier wrote:
>
> On Wed, Jul 16, 2025 at 02:32:53PM +0300, Nazir Bilal Yavuz wrote:
> > On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote:
> >> Hmm. Is that actually useful as we know that the standby has been
> >> stalen down when running the test?
On Fri, Jul 18, 2025 at 10:44 AM Dilip Kumar wrote:
>
> On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
> >
I was looking at the high level idea of sequence sync worker patch
i.e. 0005, so far I haven't found anything problematic there, but I
haven't completed the review and testing yet. Here
On Mon, 23 Jun 2025 at 11:16, Robins Tharakan wrote:
>
>
> I don't see much traction upstream. I'll be away for a few
> weeks and given that at this point, this is just noise (for us
> anyway), I've disabled these (aarch64) instances for now.
>
> I'll re-enable them once I'm back.
After some mor
On Fri, Jul 18, 2025, at 02:49, Rishu Bagga wrote:
> Hi all,
>
> There’s been some renewed attention on improving the performance of the
> LISTEN/NOTIFY system, which historically hasn’t scaled well under high
> notify frequency. Joel Jacobson recently shared some work on optimizing
> the LISTEN pa
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 follows:
>> @@ -3383,8 +3383,8 @@ readCommandResponse(CState *st, MetaCommand meta, char
>> *varprefix)
>>
>> default:
>>
Hi,
I receive data from a data provider on a daily basis, and noticed how
they use fixed type floating point in text mode, to transmit data. As
you might know, this type of transmission is not lossless.
Because the PostgreSQL binary format is not very portable across
different database providers,
On Thu, 17 Jul 2025 10:57:36 +0900
Yugo Nagata wrote:
> On Tue, 17 Jun 2025 00:08:32 +0900
> Yugo Nagata wrote:
>
> > On Thu, 5 Jun 2025 16:52:00 +0900
> > Yugo Nagata wrote:
> >
> > > On Thu, 5 Jun 2025 10:08:35 +0900
> > > Yugo Nagata wrote:
> > >
> > > > Hi,
> > > >
> > > > Currently, t
Hi All,
On Mon, Jan 27, 2025 at 11:22 AM Ashutosh Bapat
wrote:
>
> On Mon, Nov 25, 2024 at 7:06 PM Nazir Bilal Yavuz wrote:
> >
> > It is added and marked as ready for the committer [1]. There are
> > multiple 'Jian He' users in the commitfest app, so I couldn't add you
> > as a reviewer; please
Hi,
I receive data from a data provider on a daily basis, and noticed how they
use fixed type floating point in text mode, to transmit data. As you might
know, this type of transmission is not lossless.
Because the PostgreSQL binary format is not very portable across different
database providers,
94 matches
Mail list logo
