Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Wed, Jul 2, 2025 at 7:56 PM shveta malik wrote: > > Few comments: > > 1) > When the API is waiting for the primary to advance, standby fails to > handle promotion requests. Promotion fails: > ./pg_ctl -D ../../standbydb/ promote -w > waiting for server to promote.stopped waiting

Fix lwlock.c and wait_event_names.txt discrepancy

Hi hackers, While working on [1], I noticed a discrepancy between lwlock.c and wait_event_names.txt for 2 wait events. Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU in the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. That breaks joins be

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Wed, Jul 16, 2025 at 3:00 PM Ajin Cherian wrote: > > On Wed, Jul 2, 2025 at 7:56 PM shveta malik wrote: > > > > Few comments: > > > > 1) > > When the API is waiting for the primary to advance, standby fails to > > handle promotion requests. Promotion fails: > > ./pg_ctl -D ../../standbydb/ pro

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

bug: begin; drop table if exists pks cascade; create table pks(i int primary key, b int) partition by range (i); create table pks_34 partition of pks for values from (3) to (6); create table pks_d partition of pks default; insert into pks values (0), (1), (3), (4), (5); commit; alter table pks_d a

event trigger support for PL/Python

Hi, There is an old thread [1] that proposed $SUBJECT. That patch was not committed and the thread died. I use the referred patch as base for the attached version. The key differences between them are: documentation, tests, refactor (0001) and a few cleanups. [1] https://www.postgresql.org/me

Composite types for updatable views

While simple views are automatically updatable [1], this does not extend to composite types; that is, if a view constructs a composite type for one or more columns, this column then is not updatable: > A column is updatable if it is a simple reference to an updatable column of the underlying base

Re: Suggestion to add --continue-client-on-abort option to pgbench

Hi, On 2025/07/15 11:16, Yugo Nagata wrote: >> I noticed one small thing I’d like to discuss. I'm not sure that users >> clearly >> understand which aborted in the following error message, the client or the >> script. >>> pgbench: error: client 0 script 0 aborted in command ... query ... >> >> S

Re: track generic and custom plans in pg_stat_statements

On 6/30/25 13:45, Sami Imseih wrote: rebased patch. Only changes to the tests due to the revert of nested query tracking in f85f6ab051b Thank you for your efforts. I would like to share a few thoughts about this patch. First, I believe the 'status' field could be renamed to 'mode,' as it alig

Re: Saving stack space in nbtree's _bt_first function

On 16/07/2025 07:27, Peter Geoghegan wrote: [...] Rather, we rely on the generic logic that builds our startKeys[] entries. It will inevitably "break" before ever moving on to the next index attribute/next so->keyData[] key because strat_total will inevitably become BTGreaterStrategyNumber/BTLes

Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings

On 16.07.25 01:35, Peter Geoghegan wrote: On Sat, Jul 12, 2025 at 1:55 PM Andres Freund wrote: I had played with using pg_assume here too, but I couldn't really convince myself that it's a good idea... In the past, it was often necessary to work around MSVC's inability to see that a block con

Re: Improving and extending int128.h to more of numeric.c

On Tue, Jul 15, 2025 at 4:07 AM Dean Rasheed wrote: > > I have reduced the number of iterations and changed it to use the > current time for the PRNG seed. I don't see much value in logging the > seed though, since we already log the inputs that cause any failure. Ah, right. On Mon, Jun 23, 2025

Re: Improve error reporting in 027_stream_regress test

Hi, Thanks for looking into this! On Wed, 16 Jul 2025 at 04:39, Michael Paquier wrote: > > On Tue, Jul 01, 2025 at 10:57:11AM +0300, Nazir Bilal Yavuz wrote: > > On Mon, 30 Jun 2025 at 18:01, Andres Freund wrote: > >> One thing I don't yet like is that I think we should report if the primary >

Re: Fix lwlock.c and wait_event_names.txt discrepancy

On 2025-Jul-16, Michael Paquier wrote: > On Wed, Jul 16, 2025 at 09:30:31AM +, Bertrand Drouvot wrote: > > Indeed, the wait event names are MultixactOffsetSLRU and > > MultixactMemberSLRU in > > the C file but MultiXactOffsetSLRU and MultiXactMemberSLRU in the text file. > > > > That breaks

Re: Fix lwlock.c and wait_event_names.txt discrepancy

Hi, On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote: > On 2025-Jul-16, Michael Paquier wrote: > > > On Wed, Jul 16, 2025 at 09:30:31AM +, Bertrand Drouvot wrote: > > > > Indeed, the wait event names are MultixactOffsetSLRU and > > > MultixactMemberSLRU in > > > the C file but

Re: index prefetching

On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: > But the thing I don't really understand it the "cyclic" dataset (for > example). And the "simple" patch performs really badly here. This data > set is designed to not work for prefetching, it's pretty much an > adversary case. There's ~100 TIDs

Re: index prefetching

On 7/16/25 15:36, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: >> But the thing I don't really understand it the "cyclic" dataset (for >> example). And the "simple" patch performs really badly here. This data >> set is designed to not work for prefetching, it's p

Re: index prefetching

On 7/16/25 16:07, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 9:58 AM Tomas Vondra wrote: >>> The "simple" patch has _bt_readpage reset the read stream. That >>> doesn't make any sense to me. Though it does explain why the "complex" >>> patch does so many more fadvise calls. >>> >> >> Why it

Re: index prefetching

On 7/16/25 16:29, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 10:20 AM Tomas Vondra wrote: >> The read stream can only return blocks generated by the "next" callback. >> When we return the block for the last item on a leaf page, we can only >> return "InvalidBlockNumber" which means "no more

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Tue, Jul 15, 2025 at 4:31 PM Jacob Champion < jacob.champ...@enterprisedb.com> wrote > Otherwise I think we'll continue to chase weird corner cases. > Agreed. Here's a little more detail on the case I noticed: * postgres backend thread managing several libpq connections, with polling is_busy

Re: index prefetching

On Wed, Jul 16, 2025 at 10:37 AM Tomas Vondra wrote: > What sounds weird? That the read_stream works like a stream of blocks, > or that it can't do "pause" and we use "reset" as a workaround? The fact that prefetch distance is in any way affected by a temporary inability to return more blocks. Ju

Re: Changing shared_buffers without restart

> On Tue, Jul 15, 2025 at 10:52:01PM +, Jack Ng wrote: > >> On Mon, Jul 14, 2025 at 03:18:10PM +, Jack Ng wrote: > >> Just brain-storming here... would moving NBuffers to shared memory solve > >this specific issue? Though I'm pretty sure that would open up a new set of > >synchronization is

wrong sequence value in dump file

Hi, When dumping with pg_dump and the directory option, I got a sequence value that is greater in the dump file than the sequence in the source database. The sequence is defined as: CREATE SEQUENCE id_seq_test INCREMENT BY 1 MINVALUE 1 MAXVALUE 190 START 1000 CACHE 1

Re: Changing shared_buffers without restart

> On Mon, Jul 14, 2025 at 05:55:13PM -0500, Jim Nasby wrote: > > Finally, while shared buffers is the most visible target here, there are > other shared memory settings that have a *much* smaller surface area, and > in my experience are going to be much more valuable from a tuning > perspective; no

Re: wrong sequence value in dump file

Ok, effectively the dump comes from a standby. Thanks for your explanation. Best regards, Fabrice On Wed, Jul 16, 2025 at 5:06 PM Tom Lane wrote: > Fabrice Chapuis writes: > > When dumping with pg_dump and the directory option, I got a sequence > value > > that is greater in the dump file tha

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

16.07.2025 17:58, Andres Freund пишет: > Hi, > > On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote: >> On 16.06.2025 17:41, Andres Freund wrote: >>> TBH, I don't see a point in continuing with this thread without something >>> that >>> others can test. I rather doubt that the right fix here i

Re: Explicitly enable meson features in CI

On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz wrote: > > For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We > > can rename it as a 'Meson Auto Feature Detection' but that is a bit > > longer. Do you have any ideas? If you think 'Meson Auto' is good > > enough, we can continu

Re: index prefetching

On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: > For "uniform" data set, both prefetch patches do much better than master > (for low selectivities it's clearer in the log-scale chart). The > "complex" prefetch patch appears to have a bit of an edge for >1% > selectivities. I find this a bit s

Re: Fix PQport to never return NULL if the connection is valid

On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote: > I looked a bit more into the meaning of the port="" setting. The docs > for the port parameter / PGPORT env var > > say: > > An empty string, or an empty

Re: index prefetching

On Wed, Jul 16, 2025 at 9:36 AM Peter Geoghegan wrote: > Another issue with the "simple" patch: it adds 2 bool fields to > "BTScanPosItem". That increases its size considerably. We're very > sensitive to the size of this struct (I think that you know about this > already). Bloating it like this wi

Re: Suggestion to add --continue-client-on-abort option to pgbench

On Wed, 16 Jul 2025 21:35:01 +0900 Rintaro Ikeda wrote: > Hi, > > On 2025/07/15 11:16, Yugo Nagata wrote: > >> I noticed one small thing I’d like to discuss. I'm not sure that users > >> clearly > >> understand which aborted in the following error message, the client or the > >> script. > >>>

Re: index prefetching

Hi, On 2025-07-16 16:20:25 +0200, Tomas Vondra wrote: > On 7/16/25 16:07, Peter Geoghegan wrote: > >> Te pattern of fadvise+pread for the same block seems a bit silly. And > >> this is not just about "sync" method, the other methods will have a > >> similar issue with no starting the I/O earlier.

Re: index prefetching

On Wed, Jul 16, 2025 at 10:25 AM Andres Freund wrote: > This imo isn't something worth optimizing for - if you use an io_method that > actually can execute IO asynchronously this issue does not exist, as the start > of the IO will already have populated the buffer entry (without BM_VALID set, > of

Re: index prefetching

On Wed, Jul 16, 2025 at 9:58 AM Tomas Vondra wrote: > > The "simple" patch has _bt_readpage reset the read stream. That > > doesn't make any sense to me. Though it does explain why the "complex" > > patch does so many more fadvise calls. > > > > Why it doesn't make sense? The reset_stream_reset()

Re: index prefetching

On Wed, Jul 16, 2025 at 10:20 AM Tomas Vondra wrote: > The read stream can only return blocks generated by the "next" callback. > When we return the block for the last item on a leaf page, we can only > return "InvalidBlockNumber" which means "no more blocks in the stream". > And once we advance t

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-06-25 16:41:46 +0300, Sergey Shinderuk wrote: > On 16.06.2025 17:41, Andres Freund wrote: > > TBH, I don't see a point in continuing with this thread without something > > that > > others can test. I rather doubt that the right fix here is to just change > > the > > lock model over,

Re: wrong sequence value in dump file

Fabrice Chapuis writes: > When dumping with pg_dump and the directory option, I got a sequence value > that is greater in the dump file than the sequence in the source database. Perhaps you were dumping from a standby server? It's normal for a standby to show a value up to 32 counts more than th

Re: Changing shared_buffers without restart

Hi, On 2025-07-14 17:55:13 -0500, Jim Nasby wrote: > I say that because unless you're running a workload that entirely fits in > shared buffers, or a *really* small shared buffers compared to system > memory, increasing shared buffers quickly gets into diminishing returns. I don't think that's tr

Re: Read-Write optimistic lock (Re: sinvaladt.c: remove msgnumLock, use atomic operations on maxMsgNum)

Hi, On 2025-07-16 18:27:45 +0300, Yura Sokolov wrote: > 16.07.2025 17:58, Andres Freund пишет: > >> Now, if I simply remove the spinlock in SIGetDataEntries, I see a drop of > >> just ~6% under concurrent DDL. I think this strongly suggests that the > >> spinlock is the bottleneck. > > > > This c

Re: Add progressive backoff to XactLockTableWait functions

Hi all, I spent some extra time walking the code to see where XactLockTableWait() actually fires. A condensed recap: 1) Current call-paths A. Logical walsender (XLogSendLogical → … → SnapBuildWaitSnapshot) in cascading standby B. SQL slot functions (pg_logical_slot_get_changes[_peek]) create_lo

Re: Optimize LISTEN/NOTIFY

On Wed, Jul 16, 2025, at 02:20, Rishu Bagga wrote: > Hi Joel, > > Thanks for sharing the patch. > I have a few questions based on a cursory first look. > >> If a single listener is found, we signal only that backend. >> Otherwise, we fall back to the existing broadcast behavior. > > The idea of not

Re: Extend ALTER DEFAULT PRIVILEGES for large objects

On Tue, 15 Jul 2025 19:07:16 +0900 Fujii Masao wrote: > I've pushed the patch. Thanks! Thank you! > > >>> But perhaps this corner case doesn't really > >>> need to be handled? > >> > >> Probably I failed to get your point here. Could you clarify what you meant? > > > > I'm sorry for not expla

Re: Improve pg_sync_replication_slots() to wait for primary to advance

> I am not able to apply the patch to the latest head or even to a week > back version. Can you please check and rebase? > > thanks > Shveta Rebased. Regards, Ajin Cherian Fujitsu Australia. v2-0001-Improve-initial-slot-synchronization-in-pg_sync_r.patch Description: Binary data

Re: Log prefix missing for subscriber log messages received from publisher

On Wed, 16 Jul 2025 at 09:09, Fujii Masao wrote: > > > > > Included it for dblink and fdw > > Thanks! It's better to submit each change for dblink and postgres_fdw > as separate patches, and first focus on the patch that sets the notice > processor for replication connections. Modified > > > +no

Re: Fix lwlock.c and wait_event_names.txt discrepancy

On Wed, Jul 16, 2025 at 09:30:31AM +, Bertrand Drouvot wrote: > While working on [1], I noticed a discrepancy between lwlock.c and > wait_event_names.txt for 2 wait events. Oops. > Indeed, the wait event names are MultixactOffsetSLRU and MultixactMemberSLRU > in > the C file but MultiXactOff

Re: Missing NULL check after calling ecpg_strdup

Hi Michael, > depending on what's set in a URI. I think that we need to redesign a > bit ecpg_strdup(), perhaps by providing an extra input argument so as > we can detect hard failures on OOM and let ECPGconnect() return early > if we find a problem. Makes sense. In this case however I believe w

Re: Explicitly enable meson features in CI

Hi, On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz wrote: > > Hi, > > On Thu, 10 Jul 2025 at 20:12, Jacob Champion > wrote: > > > > On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz > > wrote: > > > Andres off-list mentioned that if we explicitly enable features for > > > *all* of the tasks,

Re: Question on any plans to use the Create Server/Create blink_ Mapping to provide Logical Replication Subscriptions the user/password in an encrypted manner

On Tue, Jul 15, 2025 at 7:28 PM Vitale, Anthony, Sony Music wrote: > > Hello All > > > > Postgresql dblinks and dblink_fdw allow for the use of Server and user > mapping to be able to store the user/password of a connection and save it in > an encrypted manner. > > > > Logical replication subscr

Re: Log prefix missing for subscriber log messages received from publisher

On 2025/07/16 19:45, vignesh C wrote: If we don't trim the trailing newline, an extra blank line will appear after the message is printed, like this: 2025-07-16 12:44:20.076 IST [534376] LOG: logical replication table synchronization worker for subscription "sub1", table "t2" has started 2025

Re: Explicitly enable meson features in CI

Hi, On 2025-07-16 14:12:22 +0300, Nazir Bilal Yavuz wrote: > On Fri, 11 Jul 2025 at 14:00, Nazir Bilal Yavuz wrote: > > On Thu, 10 Jul 2025 at 20:12, Jacob Champion > > wrote: > > > > > > On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz > > > wrote: > > > > Andres off-list mentioned that if w

Re: index prefetching

On Wed, Jul 16, 2025 at 11:29 AM Peter Geoghegan wrote: > For example, with "linear_10 / eic=16 / sync", it looks like "complex" > has about half the latency of "simple" in tests where selectivity is > 10. The advantage for "complex" is even greater at higher > "selectivity" values. All of the oth

Re: Collation and primary keys

On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote: > I have a radical proposal: Rather than having "initdb" default to > whatever locale is in the environment, make it default the the > builtin > provider and the C collation.  Wherever people need a natural > language > collation, they can say

Re: fix organization wording in psql's \copyright command

Committed. Thanks for the prompt reviews. On Tue, Jul 15, 2025 at 12:29:32AM +0200, Daniel Gustafsson wrote: >> On 15 Jul 2025, at 00:07, Tom Lane wrote: >> I wonder if we missed any other places ... grepping for >> "Postgres95" didn't find any, but ... > > Grepping around with a bit of fuzzy m

Re: pg_dumpall dumps global objects with --statistics-only or --no-schema

On Mon, 2025-06-30 at 16:44 -0400, Corey Huinker wrote: > > > > Since pg_dumpall treats global objects as schema-level content, it > > currently > > includes them with --schema-only but skips them with --data-only. > > By that logic, > > it should also skip them when either --statistics-only or --

Re: Saving stack space in nbtree's _bt_first function

On Wed, Jul 16, 2025 at 9:17 AM Mircea Cadariu wrote: > Thanks for the elaboration and updated patch! Indeed, I see it's set in > the ScanKeyEntryInitialize to either BTGreaterStrategyNumber or > BTLessStrategyNumber, then few lines lower there's the if with the break. > > I'm convinced. Pushed.

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote: > If one modifies libpq to use openssl readahead (which does result in speedups, > because otherwise openssl think it's useful to do lots of 5 byte reads from > the socket), I see occasional hangs in libpq. Now that is a very interesting coinc

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 7:36 AM Merlin Moncure wrote: > Agreed. Here's a little more detail on the case I noticed: > > * postgres backend thread managing several libpq connections, with polling > is_busy loop > * when client pushed a lot of log messages (say, with 'RAISE NOTICE'), the > server w

Re: index prefetching

On 7/16/25 20:18, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 1:42 PM Tomas Vondra wrote: >> On 7/16/25 16:45, Peter Geoghegan wrote: >>> I get that index characteristics could be the limiting factor, >>> especially in a world where we're not yet eagerly reading leaf pages. >>> But that in

Re: small fix for pg_overexplain docs

On Wed, 16 Jul 2025 at 22:22, Nathan Bossart wrote: > > Okay, here is a new version of the patch. > LGTM. Regards, Dean

Re: index prefetching

On Wed, Jul 16, 2025 at 5:41 PM Andres Freund wrote: > I don't mean the index tids, but how the read stream is fed block numbers. In > the "complex" patch that's done by index_scan_stream_read_next(). And the > block number it returns is simply > > return ItemPointerGetBlockNumber(tid); > >

Re: index prefetching

Hi, On 2025-07-16 17:47:53 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 5:41 PM Andres Freund wrote: > > I don't mean the index tids, but how the read stream is fed block numbers. > > In > > the "complex" patch that's done by index_scan_stream_read_next(). And the > > block number it

Re: small fix for pg_overexplain docs

On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote: > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote: >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston >> > The pg_overexplain extends EXPLAIN with new options that provide... >> > Suggest instead: >> > The pg_overexplain module provi

Re: index prefetching

On 7/16/25 16:45, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 10:37 AM Tomas Vondra wrote: >> What sounds weird? That the read_stream works like a stream of blocks, >> or that it can't do "pause" and we use "reset" as a workaround? > > The fact that prefetch distance is in any way affected b

Fix tab completion in v18 for ALTER DATABASE/USER/ROLE ... RESET

Hi hackers, These two patches are split out from my earlier thread about improving tab completion for varous RESET forms (https://postgr.es/m/87bjqwwtic@wibble.ilmari.org), so that the bug fixes can be tracked as an open item for v18. Commits 9df8727c5067 and c407d5426b87 added tab completion

Re: index prefetching

Hi, On 2025-07-16 14:30:05 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 2:27 PM Andres Freund wrote: > > Could you share the current version of the complex patch (happy with a git > > tree)? Afaict it hasn't been posted, which makes this pretty hard follow > > along > > / provide feed

Re: index prefetching

Hi, On 2025-07-16 16:54:06 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 3:40 PM Andres Freund wrote: > > As a first thing I just wanted to get a feel for the improvements we can > > get. > > I had a scale 5 tpch already loaded, so I ran a bogus query on that to see. > > Cool. > > >

Re: small fix for pg_overexplain docs

On Wed, Jul 16, 2025 at 07:45:05PM +0100, Dean Rasheed wrote: > Maybe. It's kind-of annoying that all the modules that aren't > extensions use different text. Maybe there are genuine differences -- > I didn't look too closely. It would be nice if we just had one > standard description that they all

Re: [PATCH] avoid double scanning in function byteain

Peter Eisentraut writes: > The relationship between patch 0001 and 0002 is unclear to me. Are > these incremental or alternatives? The description doesn't make this clear. It appears to me that 0002 is actually counterproductive. I cannot see a reason to get a StringInfo involved here: it add

Re: Returning nbtree posting list TIDs in DESC order during backwards scans

Hi, -    for (int i = 0; i < numKilled; i++) +    for (int i = so->currPos.firstItem; i <= so->currPos.lastItem; i++) Does the above change mean it will have to do more work in the loop? Whereas before it visited strictly killed, it now has to go through all of them? Kind regards, Mirce

Re: index prefetching

On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > Maybe I'm missing something, but the current interface doesn't seem to work > for AMs that don't have a 1:1 mapping between the block number portion of the > tid and the actual block number? I'm not completely sure what you mean here. Even w

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

Hi, On 2025-07-16 11:50:46 -0700, Jacob Champion wrote: > On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote: > > If one modifies libpq to use openssl readahead (which does result in > > speedups, > > because otherwise openssl think it's useful to do lots of 5 byte reads from > > the socket),

Re: index prefetching

Hi, On 2025-07-16 17:27:23 -0400, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > > Maybe I'm missing something, but the current interface doesn't seem to work > > for AMs that don't have a 1:1 mapping between the block number portion of > > the > > tid and the ac

Re: index prefetching

On 7/16/25 17:29, Peter Geoghegan wrote: > On Wed, Jul 16, 2025 at 4:40 AM Tomas Vondra wrote: >> For "uniform" data set, both prefetch patches do much better than master >> (for low selectivities it's clearer in the log-scale chart). The >> "complex" prefetch patch appears to have a bit of an

Re: index prefetching

On Wed, Jul 16, 2025 at 2:27 PM Andres Freund wrote: > Could you share the current version of the complex patch (happy with a git > tree)? Afaict it hasn't been posted, which makes this pretty hard follow along > / provide feedback on, for others. Sure: https://github.com/petergeoghegan/postgres

Re: small fix for pg_overexplain docs

On Wed, 16 Jul 2025 at 18:26, Nathan Bossart wrote: > > On Tue, Jul 15, 2025 at 04:14:44PM +0100, Dean Rasheed wrote: > > On Tue, 15 Jul 2025 at 04:17, Robert Treat wrote: > >> On Mon, Jul 14, 2025 at 3:22 PM David G. Johnston > >> > The pg_overexplain extends EXPLAIN with new options that provid

Re: index prefetching

Hi, On 2025-07-16 15:39:58 -0400, Andres Freund wrote: > Looking at the actual patches now. I just did an initial, not particularly in depth look. A few comments and questions below. For either patch, I think it's high time we split the index/table buffer stats in index scans. It's really ann

Re: index prefetching

On Wed, Jul 16, 2025 at 3:40 PM Andres Freund wrote: > As a first thing I just wanted to get a feel for the improvements we can get. > I had a scale 5 tpch already loaded, so I ran a bogus query on that to see. Cool. > Test: > > Peter's: To be clear, the "complex" patch is still almost all Toma

Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

Jianghua Yang writes: > By using CLOCK_MONOTONIC_COARSE, which has lower overhead compared to > CLOCK_MONOTONIC, the patch improves the efficiency of timing > collection in EXPLAIN > ANALYZE. While it may slightly reduce precision, the resulting measurements > more closely reflect actual elapsed t

Re: index prefetching

On 7/16/25 19:56, Tomas Vondra wrote: > On 7/16/25 18:39, Peter Geoghegan wrote: >> On Wed, Jul 16, 2025 at 11:29 AM Peter Geoghegan wrote: >>> For example, with "linear_10 / eic=16 / sync", it looks like "complex" >>> has about half the latency of "simple" in tests where selectivity is >>> 10.

Re: index prefetching

On Wed, Jul 16, 2025 at 4:46 PM Andres Freund wrote: > Currently the API wouldn't easily allow the table AM to do batched TID lookups > - if you have a query that looks at a lot of table tuples in the same buffer > consecutively, we spend a lot of time locking/unlocking said buffer. We also > spe

Re: track generic and custom plans in pg_stat_statements

> Ugh. This is plugging into an executor-related structure a completely > different layer, so that looks like an invasive layer violation to > me.. This is passed through ProcessQuery() from a Portal, changing > while on it ExplainOnePlan. If we want to get access from a cached > plan, wouldn't

Re: track generic and custom plans in pg_stat_statements

> this for better tracking. By adding a CachedPlanSource::cplan link, we > can establish a connection to the entire PlanCache entry instead of only > CachedPlan within a queryDesc and, consequently, make it accessible from > the executor. This would give an access to statistics on costs and the > n

Re: Improve error reporting in 027_stream_regress test

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? Even if we report something, we >> could always trim the output, li

Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

Hi, On 2025-02-28 23:45:58 -0800, Lukas Fittl wrote: > From what I can gather, it appears this was an oversight when David first > reapplied the work on the instr_time changes that were committed. Heh, glad that that's now fixed. Unfortunately the patch needs an update, primarily because of the

Re: Fix lwlock.c and wait_event_names.txt discrepancy

On Wed, Jul 16, 2025 at 11:41:09AM +, Bertrand Drouvot wrote: > On Wed, Jul 16, 2025 at 01:33:07PM +0200, Álvaro Herrera wrote: >> I don't. These names are unlikely to be anywhere other than in the >> output of queries for any length of time, so if we change them now, >> nothing will break per

Re: duplicate line in ExecEvalJsonCoercionFinish

jian he 于2025年7月17日周四 07:39写道： > hi. > > ExecEvalJsonCoercionFinish duplicate line: > jsestate->escontext.error_occurred = false; > jsestate->escontext.error_occurred = false; > > > https://git.postgresql.org/cgit/postgresql.git/tree/src/backend/executor/execExprInterp.c#n5230 G

Re: psql: tab-completion support for COPY ... TO/FROM STDIN, STDOUT, and PROGRAM

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, tab completion for COPY only suggests filenames after TO or > > > FROM, even thou

Re: simple patch for discussion

On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote: > workers, but there isn't an easy way to get more > workers. Is "alter table ... set (parallel_workers=N);" not easy enough? David

Re: duplicate line in ExecEvalJsonCoercionFinish

On Thu, Jul 17, 2025 at 10:01 AM Richard Guo wrote: > On Thu, Jul 17, 2025 at 9:52 AM Tender Wang wrote: > > jian he 于2025年7月17日周四 07:39写道： > >> ExecEvalJsonCoercionFinish duplicate line: > >> jsestate->escontext.error_occurred = false; > >> jsestate->escontext.error_occurred = f

Re: index prefetching

Hi, On 2025-07-16 14:18:54 -0400, Peter Geoghegan wrote: > I don't fully understand why this appears to be less of a problem with > the complex patch. Can you help me to confirm my understanding? Could you share the current version of the complex patch (happy with a git tree)? Afaict it hasn't be

Re: index prefetching

On Wed, Jul 16, 2025 at 3:00 PM Tomas Vondra wrote: > Yes, sounds like a fair summary. Cool. > Perhaps, although I don't quite see why the simpler patch couldn't > address some of those problems (within the limit of a single leaf page, > of course). I don't think there's anything that's prevent

Re: [PATCH] Add tests for binaryheap.c

On Fri, Jun 27, 2025 at 02:02:22PM +0300, Aleksander Alekseev wrote: >> I'm not sure I see much point in testing both min-heaps and max-heaps. The >> only difference between the two is in the comparator, so IMHO the extra >> tests really only serve to test the test comparator. > > Make sense. Her

Re: Fix PQport to never return NULL if the connection is valid

Laurenz Albe writes: > On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote: >> Please find attached a new patch that doesn't change the behaviour and >> just makes sure to not return NULL in case no info is available in >> 'conn->connhost'. > I think that it is important to fix that bug and

Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

... BTW, another resource worth looking at is src/bin/pg_test_timing/ which we just improved a few days ago [1]. What I see on two different Linux-on-Intel boxes is that the loop time that that reports is 16 ns and change, and the clock readings appear accurate to full nanosecond precision. Chang

Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote: > > Based on my understanding of [1], readahead makes this overall problem > > much worse by opportunistically slurping bytes off the wire and doing > > absolutely nothing with them until you call SSL_read() enough times to > > finally get to th

Re: index prefetching

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 from TIDs to specific > blocks & buffers happe

Re: Improve pg_sync_replication_slots() to wait for primary to advance

On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote: > > > I am not able to apply the patch to the latest head or even to a week > > back version. Can you please check and rebase? > > > > thanks > > Shveta > > Rebased. > Thanks. Please find a few comments: 1) /* Any slot with NULL in these field

Re: Conflict detection for update_deleted in logical replication

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 Kapila wrote: > > > > > > > > > I think that even with retain_conflict_info = off, there is probably a > > > > point at which the subscriber c

Re: query_id: jumble names of temp tables for better pg_stat_statement UX

On Tue, Jul 15, 2025 at 11:20 PM Alexander Kukushkin wrote: > However, we regularly hear from many different customers that they *don't > control queries* sent by application or *can't modify these queries*. > Such kinds of workloads are also not that uncommon and this change makes > it impossibl

Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION

On Fri, 4 Jul 2025 14:58:05 +0900 Yugo Nagata wrote: > On Fri, 4 Jul 2025 10:48:26 +0700 > Daniil Davydov <3daniss...@gmail.com> wrote: > > > Hi, > > > > On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote: > > > > > > On Tue, 1 Jul 2025 18:56:11 +0700 > > > Daniil Davydov <3daniss...@gmail.com>

Re: ZStandard (with dictionaries) compression support for TOAST compression

On Tue, Jul 15, 2025 at 10:37:02PM -0700, Nikhil Kumar Veldanda wrote: > 0001 – pg_compression_available() > pg_compression_available() in misc.c feels sensible; Actually, I have taken a step back on this one and recalled that the list of values available for an enum GUC are already available in p

  1   2   >