| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Greg Stark <stark(at)mit(dot)edu> |
| Cc: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, pgsql-admin(at)lists(dot)postgresql(dot)org, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Estimate maintenance_work_mem for CREATE INDEX |
| Date: | 2017-12-20 02:31:43 |
| Message-ID: | CAB7nPqRmaj6sT7RRGPdfB_Tm1WskC3jsrGtzAq=VJNOVgj5zyQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
On Tue, Dec 19, 2017 at 11:14 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> You're not the first to propose something like that. I think an
> EXPLAIN ALTER TABLE would also be very handy -- it's currently
> impossible to tell without carefully reading the source code whether a
> given DDL change will require a full table scan, a full table rewrite,
> or just a quick meta data update (and even in that case what strength
> lock will be required). I think there are other utility statements
> that make interesting heuristic decisions that would be nice to be
> able to have some visibility into -- CLUSTER comes to mind.
An application of such things is attempting to estimate the amount of
disk space needed when doing a schema upgrade, so that could be handy.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ankur Kaushik | 2017-12-20 07:33:48 | pg_basebackup Compression Problem |
| Previous Message | Alex Shulgin | 2017-12-19 22:32:33 | Re: Estimate maintenance_work_mem for CREATE INDEX |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2017-12-20 02:37:28 | Re: WIP: BRIN multi-range indexes |
| Previous Message | Thomas Munro | 2017-12-20 02:28:26 | Shouldn't execParallel.c null-terminate query_string in the parallel DSM? |