Hi,
I've attached a patch that removes an unused argument from
create_sql_command() in pgbench.c.
This originates from commit 68ab8e8ba4a4, which split process_commands()
into process_sql_command() (the predecessor of create_sql_command())
and process_backslash_command().
Regards,
Yugo Nagata
-
Andres Freund writes:
> On 2025-09-16 18:48:07 -0400, Tom Lane wrote:
>> It's not clear to me how well this approach will play with
>> non-GCC compilers.
> I'd assume we'd do something like
> #if has_attribute(nonstring)
> #define pg_nonstring __attribute__((nonstring))
> #else
> ...
> #define p
Hi,
On 2025-09-16 18:48:07 -0400, Tom Lane wrote:
> Several of the buildfarm animals seem to have been updated to
> GCC 15 over the past week or so. They are now moaning about
> various places where we're intentionally omitting a string
> terminator, eg these warnings from scorpion:
>
> scorpio
On Tuesday, September 16, 2025 11:56 AM Amit Kapila
wrote:
>
> On Tue, Sep 16, 2025 at 8:17 AM Kyotaro Horiguchi
> wrote:
> >
> > I noticed that the recent commit 0d48d393d46 introduced the following
> > three messages:
> >
> > 4793> errdetail("Retention is stopped as the apply process is not
>
On Wed, Sep 17, 2025 at 3:47 AM Dmitry Mityugov
wrote:
> I tried the patch and it works well, thanks a lot to everyone involved
> in fixing this.
Thanks for the report and confirmation! I also pinged Andres just in
case he had any objections to the approach, given that he wrote this
stuff. Nope
On Wed, 3 Sept 2025 at 23:32, Peter Eisentraut wrote:
> The variant using _Generic is not a full replacement for
> __builtin_constant_p(), because it only detects integer constant
> expressions. So for example, it wouldn't work in the use in
> src/include/utils/memutils.h, which checks for consta
On 11/08/2025 7:45 AM, Amit Kapila wrote:
Hi,
4. Triggers and Constraints
For the initial version, exclude tables with user-defined triggers or
constraints from parallel apply due to complexity in dependency
detection. We may need some parallel-apply-safe marking to allow this.
I think that
> Just my 2c while looking at this particular part of the thread. Now
> to the main patch proposed, v8 or v10..
I have been thinking about whether test coverage is worth it for temp
file logging. I think it is, but others may disagree. However, I also
don't think the current tests are correct.
F
On Fri, Sep 5, 2025 at 4:19 PM Robert Haas wrote:
> While mulling this over, I realized that this only works if you don't
> mind propagating information into the final plan regardless without
> knowing whether or not EXPLAIN was actually used. That's pretty sad,
[...]
> The simplest idea that come
Tom Lane wrote 2025-09-16 16:45:
Thomas Munro writes:
On Tue, Sep 16, 2025 at 12:51 PM Thomas Munro
wrote:
On Tue, Sep 16, 2025 at 12:05 PM Tom Lane wrote:
Oh! Yeah, that is surely broken now.
This patch seems to work OK here. The deform code is a little tricky
as you have to think car
"David G. Johnston" writes:
> More generally, maybe map all the various common accessor operators to “.”
> instead of using them directly and capture the constants when chained from
> a column.
That seems fairly useless. You still have a name that requires
double quotes, and you can't tell one o
On Mon, Sep 15, 2025 at 3:43 PM Tom Lane wrote:
> anything to the RTE's eref. While that makes your argument
> nominally true, I'd be inclined to argue that this was an oversight
> and it should have changed the alias/eref fields to look like other
> RTE_RESULTs. (I've not investigated, but I wo
On Thu, Sep 11, 2025 at 04:18:00PM -0500, Nathan Bossart wrote:
> I've committed 0001, and I plan to look closer at 0002 soon.
I ended up rewriting 0002 as an ordinary regression test, which resulted in
a much smaller patch with comparable coverage. (Yes, it needs some
comments.) Thoughts?
--
On Tue, Sep 16, 2025 at 03:00:40PM -0700, Masahiko Sawada wrote:
> Thank you for updating the patch. It seems cfbot caught a regression
> test error[1] in a 32-bit build.
- bitmap_hash [1,3,5] | 49870778
+ bitmap_hash [1,3,5] | 1509752520
This one is able the hash value computation being not po
> I don't know if this is related to the crashes, but it doesn't seem
> like a good idea to #include the function pointer stuff everywhere,
> that should probably go into src/port like the others.
Just a gentle reminder on this patch series — I’ve already rebased it on
the latest tip of master and
On Tue, Sep 16, 2025 at 02:19:05PM -0500, Sami Imseih wrote:
> On Mon, Sep 15, 2025 at 05:33:45PM -0500, Sami Imseih wrote:
>> How about renaming "statent" to "pending" in pgstat_report_inj(), as
>> well? That would be a bit more consistent with the subscription stat
>> case, at least.
>
> 0001 L
Hi,
On 2025-Sep-16, Bruce Momjian wrote:
> I am starting to get worried about the confusing of adding a REPACK
> command. We already have a lot of confusion around vacuum and analyze:
>
> * autoanalyze does vacuum and analyze
> * VACUUM FULL is much different from VACUUM
>
> It seems if we a
Hi hackers,
On 10.09.2025 16:56, Ilia Evdokimov wrote:
Unfortunately, the JOB benchmark does not contain semi join nodes.
However, TPC-DS does. I'll look for the queries with slowest planner
times there and check them.
I'll need some time to check both join and semi join cases with small
and
CI is unhappy with v6 because:
[14:37:37.742] In function ‘show_result_replacement_info’,
[14:37:37.742] inlined from ‘ExplainNode’ at explain.c:2240:4:
[14:37:37.742] explain.c:4849:33: error: ‘replacement_type’ may be
used uninitialized [-Werror=maybe-uninitialized]
[14:37:37.742] 4849 |
On Tue, Sep 16, 2025 at 9:30 AM torikoshia wrote:
> I'm not sure if this is the best approach, but I changed them to log
> nothing in these cases.
> In addition to the reason you mentioned, I found that when
> pg_log_query_plan() is executed repeatedly at very short intervals
> (e.g., every 0.01 s
I am starting to get worried about the confusing of adding a REPACK
command. We already have a lot of confusion around vacuum and analyze:
* autoanalyze does vacuum and analyze
* VACUUM FULL is much different from VACUUM
It seems if we add REPACK as a command, it is somewhere between VACUUM
FU
Hi,
On 2025-09-16 15:50:20 +0900, Michael Paquier wrote:
> On Mon, Sep 15, 2025 at 02:06:03PM +0200, Matthias van de Meent wrote:
> > Presumably this was `PgAioHandle io_handles[]` at some point, but now
> > that it's a pointer it's a proper part of the struct's own size, and
> > should be treated
On Tue, Sep 16, 2025 at 10:06 PM Mircea Cadariu
wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, p
Thanks for reporting.
On Mon, Sep 15, 2025 at 10:43:06PM +0530, DIPESH DHAMELIYA wrote:
> Starting from commit 98fc31d (PG18 only), there is a new behaviour for
> DROP OWNED BY command where it deletes entries from pg_auth_members
> (including entries with ADMIN option). This change can cause a us
Hi, Alexander!
Thank you very much for looking at the patch and providing valuable
feedback!
> This approach makes sense to me. Do you think it might have corner
cases? I suggest the test scenario might include some delay between
"UPDATE" queries. Then we can see how changing of this dela
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi,
I tested the patch with log_statement = 'all' and I con
Nathan Bossart writes:
> On Mon, Sep 15, 2025 at 10:43:06PM +0530, DIPESH DHAMELIYA wrote:
>> Starting from commit 98fc31d (PG18 only), there is a new behaviour for
>> DROP OWNED BY command where it deletes entries from pg_auth_members
>> (including entries with ADMIN option). This change can caus
Dear Hayato,
Thanks for the feedback on the patch, I'm glad the latest version looks good.
I was wondering if there is anything else I need to do on my end, or
any other process I should be aware of, for this patch to move
forward? I'm happy to make any further adjustments or provide more
informat
On Wed, Aug 6, 2025 at 12:43 PM Florents Tselai
wrote:
>
>
>
> On Wed, Aug 6, 2025 at 4:34 PM Florents Tselai
> wrote:
>>
>> Attaching v6 again because it wasn't picked up the last time.
>> Trying from Gmail's web page this time.
>>
>>
>>
>> On Tue, Aug 5, 2025 at 12:40 PM Florents Tselai
>> w
On Tue, Sep 16, 2025 at 12:04 PM Greg Burd wrote:
>
> I've re-written the set of tests as suggested (I hope!). I've not
> re-run the coverage report (yet) to ensure we're at least as well
> covered as v3, but attached is v4 for your inspection (amusement?).
> I've tried to author the SQL tests su
Added a CF entry [1] for this.
==
[1] https://commitfest.postgresql.org/patch/6062/
Kind Regards,
Peter Smith.
Fujitsu Australia
Thomas Munro writes:
> On Wed, Sep 17, 2025 at 3:47 AM Dmitry Mityugov
> wrote:
>> I tried the patch and it works well, thanks a lot to everyone involved
>> in fixing this.
> Thanks for the report and confirmation! I also pinged Andres just in
> case he had any objections to the approach, given
Few comments:
1)
The message of patch001 says:
When a sequence is synchronized to the subscriber, the page LSN of the
sequence from the publisher is also captured and stored in
pg_subscription_rel.srsublsn. This LSN will reflect the state of the
sequence at the time of synchronization. By com
Over on [1], there was some concern about having to recalculate the
TID Scan's TidList on every recheck call. This work entails
evaluating all the TID expressions, sorting the resulting list of TIDs
and deduplicating it (so that we don't scan the same TID twice).
As it turns out, it certainly is
David Rowley writes:
> On Wed, 17 Sept 2025 at 16:03, Tom Lane wrote:
>> It absolutely stands for "predicate". That's an ancient Lisp-ism.
> Thanks for the confirmation. I'm happy enough to leave the _p in
> there, but at the same time, I don't see the particular reason to
> follow some ancient
On Mon, Sep 15, 2025 at 11:50 AM Alexander Korotkov
wrote:
>
> Hi!
>
> On Tue, Aug 19, 2025 at 12:04 AM Masahiko Sawada
> wrote:
> >
> > On Mon, Aug 18, 2025 at 1:31 AM Daniil Davydov <3daniss...@gmail.com> wrote:
> > >
> > >
> > > On Fri, Aug 15, 2025 at 3:41 AM Masahiko Sawada
> > > wrote:
>
On Tue, Sep 16, 2025 at 2:17 PM Peter Smith wrote:
>
> Hi Shubham,
>
> Here are some v8 review comments.
>
> ==
> Commit message
>
> 1.
> Previously, pg_createsubscriber would fail if any specified publication
> already
> existed. Now, existing publications are reused as-is with their current
On Tue, Sep 16, 2025 at 10:07 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Doruk,
>
> Thanks for updating the patch and sorry for being late.
> The new patch looks good to me.
>
Can we think of writing a few tests for this newly exposed functionality?
--
With Regards,
Amit Kapila.
Hi,
I can reproduce the same issue using the script you provided.
I think a good way to fix would be to use `(tableoid, ctid)` together as the row
identifier in row-by-row updates/deletes. This combination is unique
across partitions and avoids the incorrect behavior, while still keeping
LIMIT su
> On 17 Sep 2025, at 09:59, David Rowley wrote:
>
> Does anyone think this is worth pursuing further?
I heard of following use-case: data transferring system partition big tables by
ctid ranges to mimic parallel secscan, but with many network connections. Some
performance improvement was cl
Added a CF entry [1] for this.
A rebase was needed. PSA patch v2.
==
[1] https://commitfest.postgresql.org/patch/6063/
Kind Regards,
Peter Smith.
Fujitsu Australia.
v2-0001-use-consistent-sgml-for-tables-and-columns.patch
Description: Binary data
On 17/09/2025 8:18 AM, Zhijie Hou (Fujitsu) wrote:
I think debug_logical_replication_streaming=immediate differs from real parallel
apply . It wasn't designed to simulate genuine parallel application because it
restricts parallelism by requiring the leader to wait for each transaction to
complet
On Wednesday, September 17, 2025 2:40 AM Konstantin Knizhnik
wrote:
> On 11/08/2025 7:45 AM, Amit Kapila wrote:
> > 4. Triggers and Constraints For the initial version, exclude tables with
> > user-defined triggers or constraints from parallel apply due to complexity
> > in
> > dependency detec
I think there is agreement that the PointerIsValid() macro is pretty
useless. This patch proposes to remove it. There have been a few
recent mini-discussions in other threads that appear to support this. [0][1]
There were the usual concerns about code churn and backpatching and so
on, but I
On Mon, Sep 15, 2025 at 10:15 PM Masahiko Sawada wrote:
>
> On Sun, Sep 14, 2025 at 7:55 PM Amit Kapila wrote:
> >
> > On Fri, Sep 12, 2025 at 11:18 PM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, Sep 11, 2025 at 9:08 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > > For the shutdown sequen
> On Sep 16, 2025, at 16:05, Maksim.Melnikov wrote:
>
> Thanks for your comment, I've attached patch version without procarray.c
> changes.
>
>
> Best regards
>
> Melnikov Maksim
>
V2 LGMT.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
On Tue, Sep 16, 2025 at 11:13 AM shveta malik wrote:
>
> >
> > I updated the patch to fix this as well.
> >
>
> Thank You for the patch. Fix looks good.
>
> Shall we update the comment:
> +# Drop the physical slot and reset the synchronized_standby_slots setting. We
> +# change this after setting
On Thu, Jul 24, 2025 at 5:44 AM Yugo Nagata wrote:
> >
> > I believe the patches implement the expected behavior, include appropriste
> > doc and test
> > modification, are in good shape overall, so if there are no objections,
> > I'll mark this as Read-for-Committer.
>
> I've updated the CF sta
Hi Aleksander,
Overall LGTM. Just a few small comments:
> On Sep 15, 2025, at 16:40, Aleksander Alekseev
> wrote:
>
> --
> Best regards,
> Aleksander Alekseev
>
1.
+ /* We can't afford to leak memory here. */
+ if (PointerGetDatum(arg1) != x)
+ pfree(arg1);
On Tue, Sep 9, 2025 at 4:56 PM Fujii Masao wrote:
> Thanks for the review! Unless there are any objections,
> I’ll run the tests again and then push the patches.
I've pushed patches 0001, 0002, and 0003. I'll push 0004 later.
Buildfarm member petalura reported a failure at [1] after 0001 was bac
Thanks for your comment, I've attached patch version without
procarray.c changes.
Best regards
Melnikov Maksim
From a7112592352756a4b41789ab7f73cd546ac7633b Mon Sep 17 00:00:00 2001
From: Maksim Melnikov
Date: Fri, 12 Sep 2025 15:17:39 +0300
Subject: [PATCH v2] Preferred use of macro GetPGPr
Hi Hackers,
$SUBJECT happens if we crash just after extending the index. Noah
Misch looked into it and came up with the steps to simulate this by
patching pgstattuple to extend each rel it visits:
--- a/contrib/pgstattuple/pgstattuple.c
+++ b/contrib/pgstattuple/pgstattuple.c
@@ -254,6 +254,
On Tue, Sep 16, 2025 at 6:11 AM Dmitry Koval wrote:
>
> 7) Additionally, I've made a numerous and small fixes for grammar to the
> docs directly to the patchset.
>
v56-0002, SPLIT PARTITION check_partitions_for_split is way too overwhelming.
Similar to transformPartitionCmdForMerge, we can put so
On 12.09.25 15:51, Peter Eisentraut wrote:
On 04.09.25 11:01, Peter Eisentraut wrote:
On 03.09.25 17:04, Peter Eisentraut wrote:
Consider a third-party extension that does something like dblink or
postgres_fdw. It will compile against a server and also a libpq.
The server and the libpq might
Tom Lane писал(а) 2025-09-16 03:31:
Dmitry Mityugov writes:
Tom Lane писал(а) 2025-09-15 23:21:
Interesting, but again, how about a stack trace?
performing post-bootstrap initialization ... TRAP: failed Assert("(X &
0x) == 0"), File:
"../../../../src/include/postgres.h",
On Mon, Sep 15, 2025 at 3:40 PM Aleksander Alekseev
wrote:
>
> > Don't these types disallow NUL bytes regardless of locale / character set?
>
> You are right, they do. Here is the patch v3 with corrected comments.
Hi Aleksander,
- * Relies on the assumption that text, VarChar, BpChar, and bytea
Hi Chao,
> 1.
>
> + /* We can't afford to leak memory here. */
> + if (PointerGetDatum(arg1) != x)
> + pfree(arg1);
> + if (PointerGetDatum(arg2) != y)
> + pfree(arg2);
> ···
>
> Should we do:
> ```
> PG_FREE_IF_COPY(arg1, 0);
> PG_FREE_IF_COPY(arg2, 1)
> ```
>
> Similar to other plac
On Thu, Sep 11, 2025 at 4:09 PM Chao Li wrote:
> Then I switched to the patch branch, it got 21 different lines. After I
> updated the 18 known changes in the out file, then it got only 3 different
> lines:
>
> ```
> - \x8135f437 | \xe1b8bf
> + \x8135f437 | \xee9f87
>
> - \xa3a0 | \xee
Hi John,
> - * Relies on the assumption that text, VarChar, BpChar, and bytea all have
> the
> - * same representation. Callers that always use the C collation (e.g.
> - * non-collatable type callers like bytea) may have NUL bytes in their
> strings;
> - * this will not work with any other coll
On Sat, Sep 13, 2025 at 9:49 PM Abhi Mehta wrote:
>
> Hi Amit,
>
>
> Really interesting proposal! I've been thinking through some of the
> implementation challenges:
>
>
> On the memory side: That hash table tracking RelationId and ReplicaIdentity
> could get pretty hefty under load. Maybe bloom
Hi Michael and Alexander,
Thank you both for your help! I really appreciate it.
As a newcomer here, I might make some mistakes, but I hope with your
guidance I can avoid making them in the future =)
> Yeah, my concern was about the duplication of the list. As long as a
> fix does not do any of t
On Mon, Sep 15, 2025 at 2:36 PM vignesh C wrote:
>
>
> This is addressed in the attached patch, also rebased the patch
> because of recent commits.
>
One of the patches conflict with recent commit 0d48d393 (launcher.c
changes) and thus needs a rebase.
thanks
Shveta
On Mon, 15 Sept 2025 at 14:36, vignesh C wrote:
>
> On Mon, 8 Sept 2025 at 12:05, Chao Li wrote:
> >
> >
> >
> > On Sep 8, 2025, at 14:00, vignesh C wrote:
> >
> >
> >
> > 1 - 0001
> > ```
> > diff --git a/src/test/regress/sql/sequence.sql
> > b/src/test/regress/sql/sequence.sql
> > index 2c220
On Mon, Sep 8, 2025 at 3:10 PM Ashutosh Bapat
wrote:
>
> On Sat, Sep 6, 2025 at 10:33 AM Dilip Kumar wrote:
> > On Wed, Aug 13, 2025 at 4:17 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > Here is the initial POC patch for this idea.
> > >
> > >
> > > If no parallel apply worker is available, the
Hi Shubham,
Here are some v8 review comments.
==
Commit message
1.
Previously, pg_createsubscriber would fail if any specified publication already
existed. Now, existing publications are reused as-is with their current
configuration, and non-existing publications are createdcautomatically wi
On Fri, Sep 12, 2025 at 8:57 AM Chao Li wrote:
> * In 0003, updated a function comment in utf8_and_gb18030.c to address John's
> comment about reference to the xml file.
Thanks, but the entire point of that comment change was to remove the
reference to the XML file, yet it didn't actually do tha
On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston
wrote:
> If there are no function names present, output “expr” in lieu of a function
> name. Then just output any columns that are present. No operators, no
> constants.
In the previous discussion, the user's expression indexes were on
these
Hi,
On 2025-09-16 15:55:49 +0300, Core Studios Inc. wrote:
> Following up to correct my previous email: the query plan did not really
> change - we see Bitmap Heap Scans even before the upgrade. Therefore, the
> query plan doesn't seem to have changed after the upgrade.
>
> However after the upgr
On Mon, Sep 1, 2025 at 08:01:48PM +0900, Yugo Nagata wrote:
> On Thu, 1 May 2025 22:44:50 -0400
> Bruce Momjian wrote:
>
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
>
> I noticed that the following commit seems to be missing from the release
On Tue, Sep 16, 2025 at 8:32 AM Tom Lane wrote:
> Question is, why should we care about that?
It's a fair question, and I can't think of any hard-and-fast reason.
However, I suspect that some users may not like it; the quick -1 from
Pavel lends credence to that theory, IMHO. People do use DDL com
Thomas Munro writes:
> On Tue, Sep 16, 2025 at 12:51 PM Thomas Munro wrote:
>> On Tue, Sep 16, 2025 at 12:05 PM Tom Lane wrote:
>>> Oh! Yeah, that is surely broken now.
> This patch seems to work OK here. The deform code is a little tricky
> as you have to think carefully about which places n
On Fri, Sep 12, 2025 at 12:02 AM Zsolt Parragi
wrote:
> I realized something incorrect in my last email: I wrote that google
> doesn't ask permission for the email/profile scope. That's not true,
> it didn't show the scope screen because I already gave permission for
> the application and it remem
> On Tue, Sep 16, 2025 at 02:35:55PM -0500, Nathan Bossart wrote:
> > On Thu, Sep 11, 2025 at 04:18:00PM -0500, Nathan Bossart wrote:
> >> I've committed 0001, and I plan to look closer at 0002 soon.
> >
> > I ended up rewriting 0002 as an ordinary regression test, which resulted in
> > a much smal
We could not pin this down to a specific query, but here's one frequent
query that is running on the said table:
piers=> EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM events
WHERE priority = 'high' and ( events.fire_at <= now() +
interval '1 hour' ) AND ( events.fi
On Tue, Sep 16, 2025 at 7:42 PM Álvaro Herrera wrote:
> Peter E suggested that since we have REINDEX to rewrite indexes, then
> the command to rewrite tables should be RETABLE. I haven't been able to
> get myself to like that idea, and also I think that was a bit
> tongue-in-cheek, but if you lik
Hi Maxim
Thanks for your continued efforts to get XID64 implemented.
> 32kB page may contain then 2^13-2 offsets, each is maxed by 2^18+1.
> Therefore, offset from base will never overflow 2^31 and will always
> fit uint32.
> It appears logical to me.
Agree +1 , but I have a question: I rememb
Hi,
On September 16, 2025 7:57:54 AM EDT, "Core Studios Inc."
wrote:
>Hello,
>
>We noticed a sustained increased in IO Wait of read queries after upgrading
>from 13.13 to 13.21. Eventually, we narrowed it down to a spike in
>index_blocks_read of a certain table where Bitmap Heap Scans do happ
Robert Haas writes:
> On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston
> wrote:
>> If there are no function names present, output “expr” in lieu of a function
>> name. Then just output any columns that are present. No operators, no
>> constants.
> In the previous discussion, the user's exp
"David G. Johnston" writes:
> I fear consistently exceeding 63 bytes of identifier length if we choose to
> display the entire expression in the name.
I was worried about that too, but at least among our regression test
cases, there are none that come even close to 63 bytes under this
proposal.
On Tuesday, September 16, 2025, Robert Haas wrote:
> On Tue, Sep 16, 2025 at 12:56 AM David G. Johnston
> wrote:
> > If there are no function names present, output “expr” in lieu of a
> function name. Then just output any columns that are present. No
> operators, no constants.
>
> In the previ
On Tue, Sep 16, 2025 at 2:04 AM Michael Paquier wrote:
> one SQL function mapping to each C function we are testing?
Yes, I think we should do this, if possible.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hello,
We noticed a sustained increased in IO Wait of read queries after
upgrading from 13.13 to 13.21. Eventually, we narrowed it down to a
spike in index_blocks_read of a certain table where Bitmap Heap Scans do
happen.
Do you think that this change (i.e. removing the optimization) could b
On 2025-09-10 02:59, Robert Haas wrote:
I haven't had time to review this in a while -- sorry about that --
and I have only limited time now, but let me try to give you some
comments in the time that I do have.
Thank you very much for taking the time to review this!
I bet some users would rea
On Tue, Sep 16, 2025 at 11:53 AM shveta malik
wrote:
>
> On Mon, Sep 15, 2025 at 6:17 PM Ajin Cherian wrote:
> >
> > On Wed, Sep 10, 2025 at 2:45 PM shveta malik
wrote:
> > >
> > > On Tue, Sep 9, 2025 at 5:37 PM Ajin Cherian wrote:
> > > >
> > > > Attached v11 patch addressing the above comment
On Sep 16 2025, at 8:02 am, Robert Haas wrote:
> On Tue, Sep 16, 2025 at 2:04 AM Michael Paquier wrote:
>> one SQL function mapping to each C function we are testing?
>
> Yes, I think we should do this, if possible.
Michael, Robert,
Thanks for your time reviewing the proposed code and for
On Sun, Aug 31, 2025 at 10:53:23PM +0200, Jelte Fennema-Nio wrote:
> On Fri, 2 May 2025 at 04:45, Bruce Momjian wrote:
> >
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
>
> Since we're getting close to the release. I wanted to call out that I
>
86 matches
Mail list logo
