Re: Reduce "Var IS [NOT] NULL" quals during constant folding

Dear Team, In continuation with the previous mail (CAAh00ETEMEXntw1gxp=xP+4sqrz80tK1R4VEhTpqH9CJpxs-wA) regarding the optimizations in PostgreSQL 18 to simplify query plans by folding away Var IS [NOT] NULL checks on columns declared NOT NULL. I experimented with two approaches, but both hit signi

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

Dear Team, With reference to the conversation ongoing in message ID : c562dc2a-6e36-46f3-a5ea-cd42eebd7118, As a follow-up to the skip scan regression discussion, I tested a small patch that introduces *static allocation/caching of `IndexAmRoutine` *objects in `amapi.c`, removing the malloc/free o

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

Hi Team, As a follow-up to the skip scan regression discussion, I tested a small patch that introduces *static allocation/caching of `IndexAmRoutine` *objects in `amapi.c`, removing the malloc/free overhead. *Test setup :* - Baseline: PG17 (commit before skip scan) - After: PG18 build with skip s

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

Dear Team, With reference to the conversation ongoing in message ID : c562dc2a-6e36-46f3-a5ea-cd42eebd7118, I am writing to express my interest in contributing to the ongoing work on fixing the bug related to Adding skip scan (including MDAM style range skip scan) to nbtree. I tried to replicate

Re: Adding skip scan (including MDAM style range skip scan) to nbtree

Dear Team, With reference to the conversation ongoing in message ID : c562dc2a-6e36-46f3-a5ea-cd42eebd7118, I am writing to express my interest in contributing to the ongoing work on fixing the bug related to Adding skip scan (including MDAM style range skip scan) to nbtree. I have been following

Reduce "Var IS [NOT] NULL" quals during constant folding

*Subject:* Contribution Interest – Bug Fix on Reducing "Var IS [NOT] NULL" Quals During Constant Folding Dear Team, I hope this message finds you well. With reference to the conversation ongioing in message ID: (CAMbWs487wxHq0fUu+Cew7Y+n+wpY_B--PT-61syXrE40uZqErw

Re: GRANT/REVOKE locking semantics in get_object_address()

Dear Team, With reference to the conversation ongioing in message ID: d2d96fe4-6b1c-4bd3-813b-c2cfcb4a79f4, I am writing to express my interest in contributing to the ongoing work on fixing the bug related to Proper object locking for GRANT/REVOKE. I have been following the discussion around the

Re: Test mail for pgsql-hackers

> > Hi , > I’ve been exploring logical replication and noticed that if the column > datatypes don’t match between the publisher and subscriber, PostgreSQL > doesn’t give a warning. This can cause unexpected behavior, and I thought > it might be helpful to alert users when this happens. > ###