I want a postgres function to generate ctid where condition for table migration based ctid

for instance, select * from tabxxx where ctid >= '(0,0)' AND ctid <= '(27,0)' select * from tabxxx where ctid > '(27,0)' AND ctid <= '(57,0)' select * from tabxxx where ctid > '(57,0)' AND ctid <= '(69,0)' and so on I want to generate a table ‘s ctid condition automatically

Re: Lets prohibit predicting the future in the documentation.

On Thu, Jul 31, 2025 at 4:24 PM Peter Smith wrote: > On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander > wrote: > > > > > > > > On Thu, Jul 31, 2025 at 5:03 AM David Rowley > wrote: > >> > >> On Thu, 31 Jul 2025 at 14:17, David G. Johnston > >> wrote: > >> > > >> > Came across this again today..

Re: Lets prohibit predicting the future in the documentation.

On Thu, Jul 31, 2025 at 8:05 PM Magnus Hagander wrote: > > > > On Thu, Jul 31, 2025 at 5:03 AM David Rowley wrote: >> >> On Thu, 31 Jul 2025 at 14:17, David G. Johnston >> wrote: >> > >> > Came across this again today...we added, way back in v11: >> > >> > "This limitation will likely be removed

Re: further clarification: alter table alter column set not null - table scan is skipped

I like your versions that emphasize: don’t drop the constraint in the same alter table set no null command. Similar to David’s point, I spent some time trying to figure out a simple refactoring to carry the optimization all the way to the end but it might require executing “set not null” sooner

further clarification: alter table alter column set not null - table scan is skipped

On Thursday, July 31, 2025, Álvaro Herrera wrote: > On 2025-Jul-30, David G. Johnston wrote: > > > On Wed, Jul 30, 2025, 13:55 PG Doc comments form > > > wrote: > > > > The "table scan is skipped" optimization can use some clarification > > > > > > https://www.postgresql.org/docs/current/sql-alt

Re: further clarification: alter table alter column set not null - table scan is skipped

On 2025-Jul-30, David G. Johnston wrote: > On Wed, Jul 30, 2025, 13:55 PG Doc comments form > wrote: > > The "table scan is skipped" optimization can use some clarification > > > > https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DESC-SET-DROP-NOT-NULL > > My proposal i

Re: Lets prohibit predicting the future in the documentation.

On Thu, Jul 31, 2025 at 5:03 AM David Rowley wrote: > On Thu, 31 Jul 2025 at 14:17, David G. Johnston > wrote: > > > > Came across this again today...we added, way back in v11: > > > > "This limitation will likely be removed in a future version of > PostgreSQL." > > > > https://www.postgresql.or