| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zhihong Yu <zyu(at)yugabyte(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Yuzuko <yuzukohosoya(at)gmail(dot)com> |
| Subject: | Re: pgsql: autovacuum: handle analyze for partitioned tables |
| Date: | 2021-04-09 21:45:08 |
| Message-ID: | 20210409214508.GV6592@telsasoft.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Fri, Apr 09, 2021 at 05:31:55PM -0400, Alvaro Herrera wrote:
> On 2021-Apr-09, Robert Haas wrote:
>
> > Does this need to worry about new partitions getting attached to a
> > partitioned table, or old ones getting detached? (Maybe it does
> > already, not sure.)
>
> Good question. It does not.
I think there's probably cases where this is desirable, and cases where it's
undesirable, so I don't think it's necessarily a problem.
One data point: we do DETACH/ATTACH tables during normal operation, before
type-promoting ALTERs, to avoid worst-case disk use, and to avoid locking the
table for a long time. It'd be undesirable (but maybe of no great consequence)
to trigger an ALTER when we DETACH them, since we'll re-ATTACH it shortly
afterwards.
However, I think DROP should be handled ?
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-04-09 21:53:08 | Re: pgsql: autovacuum: handle analyze for partitioned tables |
| Previous Message | Peter Eisentraut | 2021-04-09 21:37:14 | pgsql: doc: Fix man page whitespace issues |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-04-09 21:53:08 | Re: pgsql: autovacuum: handle analyze for partitioned tables |
| Previous Message | Alvaro Herrera | 2021-04-09 21:31:55 | Re: pgsql: autovacuum: handle analyze for partitioned tables |