| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: why there is not VACUUM FULL CONCURRENTLY? |
| Date: | 2024-07-21 15:23:24 |
| Message-ID: | CAFj8pRD2zGwNX_LKy_uMGiqRfRPrk9mb0mqEVFsyhaePyL8B0g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi
ne 21. 7. 2024 v 17:13 odesílatel Kirill Reshke <reshkekirill(at)gmail(dot)com>
napsal:
> Hi!
> I'm interested in the vacuum concurrently feature being inside the
> core, so will try to review patch set and give valuable feedback. For
> now, just a few little thoughts..
>
>
>
> One more thing is about pg_squeeze background workers. They act in an
> autovacuum-like fashion, aren't they? Maybe we can support this kind
> of relation processing in core too?
>
I don't think it is necessary when this feature will be an internal
feature.
I agree so this feature is very important, I proposed it (and I very happy
so Tonda implemented it), but I am not sure, if usage of this should be
automatized, and if it should be, then
a) probably autovacuum should do,
b) we can move a discussion after vacuum full concurrently will be merged
to upstream, please. Isn't very practical to have too many open targets.
Regards
Pavel
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michail Nikolaev | 2024-07-21 15:27:01 | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
| Previous Message | Kirill Reshke | 2024-07-21 15:13:11 | Re: why there is not VACUUM FULL CONCURRENTLY? |