On Monday, July 15, 2024, sud wrote:
>
> Thank you for the confirmation.
> And if someone wants to fully remove that column from the table , then the
> only option is to create a new table with an exact set of active columns
> and insert the data into that from the existing/old table and then ren
On Tue, Jul 16, 2024 at 10:26 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>
> On Monday, July 15, 2024, David G. Johnston
> wrote:
>
>> On Monday, July 15, 2024, sud wrote:
>>
>>>
>>> However even with "vacuum full", the old rows will be removed completely
>>> from the storage ,
On Monday, July 15, 2024, David G. Johnston
wrote:
> On Monday, July 15, 2024, sud wrote:
>
>>
>> However even with "vacuum full", the old rows will be removed completely
>> from the storage , but the new rows will always be there with the 'dropped'
>> column still existing under the hood along
On Monday, July 15, 2024, sud wrote:
>
> However even with "vacuum full", the old rows will be removed completely
> from the storage , but the new rows will always be there with the 'dropped'
> column still existing under the hood along with the table storage, with
> just carrying "null" values
On Tue, Jul 16, 2024 at 6:07 AM Peter J. Holzer wrote:
>
> > But the only issue would be "VACUUM FULL" will take a table lock and
> also it
> > may take longer to run this vacuum on the full table considering the
> size of
> > the table in TB's. Thus, is it fine to just leave it post execution of
On 2024-07-16 02:00:27 +0530, sud wrote:
>
> On Mon, Jul 15, 2024 at 7:58 PM Peter J. Holzer wrote:
> > Hm, true.
> >
> > You can always do
> >
> > UPDATE tab SET id = id;
> >
> > followed by
> >
> > VACUUM (FULL) tab;
>
> Yes, that should work. It nee
On Mon, Jul 15, 2024 at 7:58 PM Peter J. Holzer wrote:
>
> > Hm, true.
> >
> > You can always do
> >
> > UPDATE tab SET id = id;
> >
> > followed by
> >
> > VACUUM (FULL) tab;
>
> Yes, that should work. It needs about twice the size of the table in
> temporary space, though.
>
> Since the OP
On 2024-07-15 13:53:25 +0200, Laurenz Albe wrote:
> On Sun, 2024-07-14 at 00:05 +0200, Peter J. Holzer wrote:
> > On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> > > Dropping a column is fast, but doesn't reclaim the space.
> > > VACUUM won't block anything, but won't reclaim the space.
> > > V
On Sun, 2024-07-14 at 00:05 +0200, Peter J. Holzer wrote:
> On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> > On Thu, 2024-07-11 at 13:10 +0530, sud wrote:
> > > Dropping will take it's own time for post vacuum however as you
> > > rightly said, it won't be blocking which should be fine.
> >
On 2024-07-11 10:06:47 +0200, Laurenz Albe wrote:
> On Thu, 2024-07-11 at 13:10 +0530, sud wrote:
> > Dropping will take it's own time for post vacuum however as you
> > rightly said, it won't be blocking which should be fine.
>
> I am not certain if you understood this correctly.
>
> Dropping a
On 2024-Jul-11, Ron Johnson wrote:
> Anyway, DROP is the easy part; it's ADD COLUMN that can take a lot of time
> (depending on whether or not you populate the column with a default value).
Actually, ADD COLUMN with a default does not rewrite the entire table
either, starting from pg11.
"Major e
On Thu, Jul 11, 2024 at 3:41 AM sud wrote:
>
>
> On Thu, 11 Jul, 2024, 12:46 pm Ron Johnson,
> wrote:
>
>> On Wed, Jul 10, 2024 at 11:28 PM sud wrote:
>>
>>>
>>>
>>>
>>> Thank you so much. When you said *"you can execute one of the forms of
>>> ALTER TABLE that performs a rewrite*
>>> *of the w
On Thu, 2024-07-11 at 13:10 +0530, sud wrote:
> Dropping will take it's own time for post vacuum however as you
> rightly said, it won't be blocking which should be fine.
I am not certain if you understood this correctly.
Dropping a column is fast, but doesn't reclaim the space.
VACUUM won't blo
On Thu, 11 Jul, 2024, 12:46 pm Ron Johnson, wrote:
> On Wed, Jul 10, 2024 at 11:28 PM sud wrote:
>
>>
>>
>>
>> Thank you so much. When you said *"you can execute one of the forms of
>> ALTER TABLE that performs a rewrite*
>> *of the whole table."* Does it mean that post "alter table drop column"
On Wed, Jul 10, 2024 at 11:28 PM sud wrote:
>
> On Thu, Jul 11, 2024 at 2:52 AM Adrian Klaver
> wrote:
>
>>
>> https://www.postgresql.org/docs/current/sql-altertable.html
>>
>> "The DROP COLUMN form does not physically remove the column, but simply
>> makes it invisible to SQL operations. Subseq
On Thu, Jul 11, 2024 at 2:52 AM Adrian Klaver
wrote:
>
> https://www.postgresql.org/docs/current/sql-altertable.html
>
> "The DROP COLUMN form does not physically remove the column, but simply
> makes it invisible to SQL operations. Subsequent insert and update
> operations in the table will stor
On 7/10/24 13:13, sud wrote:
Hi All,
It's postgres database version 15.4. We have a table which is daily and
is approx. ~2TB in size having a total ~90 partitions. We have a
requirement to drop columns and add new columns to this table.
I Want to understand, If this can be done online? what i
Hi All,
It's postgres database version 15.4. We have a table which is daily and is
approx. ~2TB in size having a total ~90 partitions. We have a requirement
to drop columns and add new columns to this table.
I Want to understand, If this can be done online? what is the fastest way
to drop/add colu
18 matches
Mail list logo
