| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Michael Harris <harmic(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, postgres(at)jeltef(dot)nl, ilya(dot)evdokimov(at)tantorlabs(dot)com |
| Subject: | Re: ANALYZE ONLY |
| Date: | 2024-08-22 02:09:12 |
| Message-ID: | CAApHDvp4ry6L4dOEU-87R7KAVsPmxySxCJBtDVXN6hJPg1ic=w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 22 Aug 2024 at 13:38, Michael Harris <harmic(at)gmail(dot)com> wrote:
> Would we want to apply that change to VACUUM too? That might be a
> bit drastic, especially if you had a multi-level inheritance structure featuring
> large tables.
I think they'd need to work the same way as for "VACUUM (ANALYZE)", it
would be strange to analyze some tables that you didn't vacuum. It's
just a much bigger pill to swallow in terms of the additional effort.
> It feels a bit like VACUUM and ANALYZE have opposite natural defaults here.
> For VACUUM it does not make much sense to vacuum only at the partitioned
> table level and not include the partitions, since it would do nothing
> - that might
> be why the existing code always adds the partitions.
Yeah, I suspect that's exactly why it was coded that way.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2024-08-22 02:47:00 | Re: Vacuum statistics |
| Previous Message | jian he | 2024-08-22 02:02:05 | Re: pgsql: Add more SQL/JSON constructor functions |