public inbox for [email protected]help / color / mirror / Atom feed
Re: Dropping column from big table 4+ messages / 3 participants [nested] [flat]
* Re: Dropping column from big table @ 2024-07-11 07:40 sud <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: sud @ 2024-07-11 07:40 UTC (permalink / raw) To: Ron Johnson <[email protected]>; +Cc: pgsql-general <[email protected]> On Thu, 11 Jul, 2024, 12:46 pm Ron Johnson, <[email protected]> wrote: > On Wed, Jul 10, 2024 at 11:28 PM sud <[email protected]> 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" >> the vacuum is going to run longer as it will try to clean up all the rows >> and recreate the new rows? But then how can this be avoidable or made >> better without impacting the system performance >> > > "Impact" is a non-specific word. "How much impact" depends on how many > autovacuum workers you've set it to use, and how many threads you set in > vacuumdb. > > >> and blocking others? >> > > VACUUM never blocks. > > 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). > > I'd detach all the partitions from the parent table, and then add the new > column to the not-children in multiple threads, add the column to the > parent and then reattach all of the children. That's the fastest method, > though takes some time to set up. > Thank you so much. Dropping will take it's own time for post vacuum however as you rightly said, it won't be blocking which should be fine. In regards to add column, Detaching all partitions then adding column to the individual partition in multiple sessions and then reattaching looks to be a really awesome idea to make it faster. However one doubt, Will it create issue if there already exists foreign key on this partition table or say it's the parent to other child partition/nonpartition tables? ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dropping column from big table @ 2024-07-11 08:06 Laurenz Albe <[email protected]> parent: sud <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Laurenz Albe @ 2024-07-11 08:06 UTC (permalink / raw) To: sud <[email protected]>; Ron Johnson <[email protected]>; +Cc: pgsql-general <[email protected]> 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 block anything, but won't reclaim the space. VACUUM (FULL) will block everything, but will also not reclaim the space. You'd need to use a form of ALTER TABLE that rewrites the table, as indicated in the documentation. However, such an operation will block all access to the table for a long time, and it will temporarily need much more space, because it has to hold both the old and the new copy of the table. Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dropping column from big table @ 2024-07-13 22:05 Peter J. Holzer <[email protected]> parent: Laurenz Albe <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Peter J. Holzer @ 2024-07-13 22:05 UTC (permalink / raw) To: [email protected] 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 column is fast, but doesn't reclaim the space. > VACUUM won't block anything, but won't reclaim the space. > VACUUM (FULL) will block everything, but will also not reclaim the space. > > You'd need to use a form of ALTER TABLE that rewrites the table, > as indicated in the documentation. Unfortunately the documentation indicates very little. It mentions that the table will be rewritten with * SET ACCESS METHOD * a volatile DEFAULT * changing the type of an existing column (unless binary coercible) All three change something which you probably don't want to change. The documentation also mentions some cases where the table is not rewritten, so maybe some not explicitely mentioned options rewrite the table, too. I would especially expected ALTER TABLE ... CLUSTER to do this, but if VACUUM FULL preserves the (former) content of dropped columns, maybe CLUSTER does, too? hp -- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | [email protected] | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" Attachments: [application/pgp-signature] signature.asc (833B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Dropping column from big table @ 2024-07-15 11:53 Laurenz Albe <[email protected]> parent: Peter J. Holzer <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Laurenz Albe @ 2024-07-15 11:53 UTC (permalink / raw) To: Peter J. Holzer <[email protected]>; [email protected] 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. > > > > I am not certain if you understood this correctly. > > > > Dropping a column is fast, but doesn't reclaim the space. > > VACUUM won't block anything, but won't reclaim the space. > > VACUUM (FULL) will block everything, but will also not reclaim the space. > > > > You'd need to use a form of ALTER TABLE that rewrites the table, > > as indicated in the documentation. > > Unfortunately the documentation indicates very little. It mentions that > the table will be rewritten with > > * SET ACCESS METHOD > * a volatile DEFAULT > * changing the type of an existing column (unless binary coercible) > > All three change something which you probably don't want to change. Hm, true. You can always do UPDATE tab SET id = id; followed by VACUUM (FULL) tab; Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-07-15 11:53 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-07-11 07:40 Re: Dropping column from big table sud <[email protected]> 2024-07-11 08:06 ` Laurenz Albe <[email protected]> 2024-07-13 22:05 ` Peter J. Holzer <[email protected]> 2024-07-15 11:53 ` Laurenz Albe <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox