From: | Michael Harris <harmic(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, 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 01:37:52 |
Message-ID: | CADofcAW=JDNdPy=dbQK9b4AsZKbqdSDTwg2=fkriq+KbnDZ-DA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah, my thought was to change the behavior so it's consistent in
> that case too. This doesn't seem to me like a change that'd
> really cause anybody serious problems: ANALYZE without ONLY would
> do more than before, but it's work you probably want done anyway.
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.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-08-22 01:49:48 | Re: Create syscaches for pg_extension |
Previous Message | Andy Fan | 2024-08-22 01:18:56 | Measure the servers's IO performance |