Re: Standardize the definition of the subtype field of AlterDomainStmt

HI Thank you for your update ，I marked the path as "Ready for Committer" Thank On Wed, May 28, 2025 at 10:27 AM Quan Zongliang wrote: > > > On 2025/5/27 11:54, Michael Paquier wrote: > > On Tue, May 27, 2025 at 11:06:46AM +0800, Quan Zongliang wrote: > >> I noticed that the subtype of AlterDo

Re: Should we optimize the `ORDER BY random() LIMIT x` case?

Hi Aleksander if we can optimize the query， that would be great，Then we won't need to pull a lot of data to the program end and randomly pick the needed data there. On Thu, 15 May 2025 at 07:41, Aleksander Alekseev wrote: > Hi, > > If I didn't miss anything, currently we don't seem to support s

Re: Pathify RHS unique-ification for semijoin planning

On Thu, 22 May 2025 at 17:28, Andy Fan wrote: > Richard Guo writes: > > Hi, > > > However, in the case of sort-based implementation, > > this function pays no attention to the subpath's pathkeys or the > > pathkeys of the resulting output. > > Good finding! > > > > > In addition to this specific

Re: Retiring some encodings?

HI > The obvious question is how many people would suffer because > of that removal, as it would prevent them from using pg_upgrade. > Can anybody who works in a region that uses these encodings make > an educated guess? +1 Agree ,GB18030 A coding standard in China, if deleted, will have an impact

Re: Proposal: Native High Availability and Automatic Failover in PostgreSQL

HI Ale Rox I've been thinking like you for a long time, But it's not so easy to realise this, there are more oppositions than approvals，You can search for this title (Re: Built-in Raft replication) On Wed, Jun 25, 2025 at 3:26 PM Ale Rox wrote: > Dear all, > > I've been using PostgreSQL for a

Re: Proposal: Global Index for PostgreSQL

Hi Dilip Kumar Thank you for your working on this ,I remember six years ago there was talk about global index ，You can see if this mailing list has any references to ( https://www.postgresql.org/message-id/CALtqXTcurqy1PKXzP9XO%3DofLLA5wBSo77BnUnYVEZpmcA3V0ag%40mail.gmail.com ) Thanks On Fri

Re: [PATCH] Refactor: Extract XLogRecord info

HI > FWIW, I'm not sure what's the benefit of the proposal which comes down > to the removal of a bitwise NOT, except more code conflicts with back > branches. Agree On Tue, Jun 10, 2025 at 3:37 PM Michael Paquier wrote: > On Mon, Jun 09, 2025 at 10:54:43PM -0300, Fabrízio de Royes Mello wrote:

Re: Add log_autovacuum_{vacuum|analyze}_min_duration

HI I vote log_autovacuum_{vacuum|analyze}_min_duration. Then don't remove log_autovacuum_min_duration so easily! On Wed, Jun 4, 2025 at 7:16 AM Fujii Masao wrote: > > > On 2025/06/04 4:32, Sami Imseih wrote: > >> On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote: > >>> On Tue, Jun 03

Re: [PATCH] Refactor: Extract XLogRecord info

HI > And I suggest to create a macro to do this job. >#define getRmgrInfo(info) (info & XLR_RMGR_INFO_MASK) > > Then the code can become: > XLogRecGetInfo(record) & ~XLR_INFO_MASK; > --> > getRmgrInfo(XLogRecGetInfo(record)) +1 Agreed, this makes the code more readable. Thanks On Mon, Jun

Re: Requested WAL segment xxx has already been removed

HI >What is really painful right now, logical walsenders can only look into pg_wal, and unfortunately replication slots don't give 100% guarantee for WAL >retention because of max_slot_wal_keep_size. >That is, using restore_command for logical walsenders would be really helpful and solve some probl

Re: Small optimization with expanding dynamic hash table

Hi > The v2 patch maybe more clear: > We can calc bucket just by hashvalue & high_mask when expanding table because the if condition in calc_bucket() must be false. I think you may add a comment to this path so that code reviewers can clearly see your optimization. Thanks On Thu, Jul 10, 2025 at

Re: Making pg_rewind faster

Hi > Thanks, LGTM. I think it's possible to register to https://commitfest.postgresql.org/54, https://commitfest.postgresql.org/53 will closed soon Thanks On Fri, Jul 4, 2025 at 10:50 AM Japin Li wrote: > On Thu, 03 Jul 2025 at 12:59, John H wrote: > > Hi, > > > > On Wed, Jul 2, 2025 at 6:40

Re: Making pg_rewind faster

HI > 2. > Perhaps decide_wal_file_action() could be defined in filemap.c. > While this is unrelated to WAL logging, it could also contribute to faster > pg_rewind operations. Should we consider ignoring log files under PGDATA > (e.g., those in the default log/ directory)? Agree ，Usually the lo

Re: Memoize ANTI and SEMI JOIN inner

HI > - if (!extra->inner_unique && (jointype == JOIN_SEMI || > - jointype == JOIN_ANTI)) > + if ((jointype == JOIN_SEMI || jointype == JOIN_ANTI) && > + !extra->inner_unique) To be nitpicky, this change is meant to align with the earlier comment modifications to improve code readability, right? Ev

Re: A concurrent VACUUM FULL?

HI Erik Nordström In online production environments, blocking writes is generally unacceptable in most cases. The only acceptable approach is to allow concurrent read/write operations, with brief locks permitted only during the final steps of the process. We can see pg-osc's implementation ( h

Re: Requested WAL segment xxx has already been removed

HI Japin Thank you for your working on this.It is useful ,when a standby node has hardware issue repaired ，wal log usually has been archived.The wal_keep_size parameter is difficult to estimate accurately, as hardware repair or replacement times are often unpredictable. If the machine can be fix

Re: Pathify RHS unique-ification for semijoin planning

HI > This is a very interesting observation. In fact, with the original v5 > patch, you can produce both plans by setting enable_hashagg on and > off. > set enable_hashagg to on; > Incremental Sort (cost=91.95..277.59 rows=2500 width=16) >(actual time=31.960..147.040 rows

Re: GB18030-2022 Support in PostgreSQL

Hi 😂，Not long ago, many people were rushing to remove this character set because of a security vulnerability. I was honestly quite shocked when I saw it. Thanks On Mon, Aug 4, 2025 at 4:08 PM JiaoShuntian wrote: > Hi hackers, > > I noticed that PostgreSQL currently supports GB18030 encodin

Re: Pathify RHS unique-ification for semijoin planning

HI Richard Guo +/* + * Is given relation unique-ified? + * + * When the nominal jointype is JOIN_INNER, sjinfo->jointype is JOIN_SEMI, and + * the given rel is exactly the RHS of the semijoin, it indicates that the rel + * has been unique-ified. + */ +#define IS_UNIQUEIFIED_REL(rel, sjinfo, nominal

<    1   2