Committed with the following small changes:
* I renamed the new option to --missing-stats-only, which I felt was more
descriptive.
* I moved the new tests to the main vacuumdb test file and interspersed
some --analyze-only uses.
* I fixed a couple of other things in the new parts of the cata
>
>
> While preparing this for commit, I noticed that the expression index part
> of the query was disregarding attstattarget. To fix, I've modified that
> part to look at the index's pg_attribute entries.
>
+1, should have been there all along.
On Fri, Mar 14, 2025 at 02:05:30PM -0500, Nathan Bossart wrote:
> If no feedback or objections materialize, I'm planning to commit these
> early next week.
While preparing this for commit, I noticed that the expression index part
of the query was disregarding attstattarget. To fix, I've modified
On Fri, Mar 7, 2025 at 4:47 AM Nathan Bossart wrote:
>
> On Thu, Mar 06, 2025 at 06:30:59PM +0700, John Naylor wrote:
> > IIUC correctly, pg_statistic doesn't store stats on itself, so this
> > causes the query result to always contain pg_statistic -- does that
> > get removed elsewhere?
>
> Good
On Wed, Mar 12, 2025 at 12:00 AM Nathan Bossart
wrote:
>
> On Mon, Mar 10, 2025 at 10:08:49AM -0500, Nathan Bossart wrote:
> > On Mon, Mar 10, 2025 at 12:35:22PM +0700, John Naylor wrote:
> >> I have no further comments.
> >
> > Thanks. I'll give this a little more time for review before committi
On Mon, Mar 10, 2025 at 12:35:22PM +0700, John Naylor wrote:
> I have no further comments.
Thanks. I'll give this a little more time for review before committing.
We'll still need to update the recommendation in pg_upgrade's
documentation. I'm going to keep that separate because the stats
impor
On Thu, Mar 06, 2025 at 06:30:59PM +0700, John Naylor wrote:
> +This option can only be used in conjunction with
> +--analyze-only and
> --analyze-in-stages.
>
> + /* Prohibit --missing-only without --analyze-only or --analyze-in-stages */
> + if (vacopts.missing_only && !vacopts.a
Out of curiosity, I generated many relations with the following command
(stolen from [0]):
do $$
begin
for i in 1..10 loop
execute format('create table t%s (f1 int unique, f2 int unique);', i);
execute format('insert into t%s select x, x from generate_series(1,1000) x',
i)
On Wed, Mar 12, 2025 at 01:56:04PM +0700, John Naylor wrote:
> The change here seems fine. My only quibble is that this sentence now
> seems out of place: "Option --analyze-in-stages can be used to
> generate minimal statistics quickly." I'm thinking we should make a
> clearer separation for with a
On Mon, Mar 10, 2025 at 10:08:49AM -0500, Nathan Bossart wrote:
> On Mon, Mar 10, 2025 at 12:35:22PM +0700, John Naylor wrote:
>> I have no further comments.
>
> Thanks. I'll give this a little more time for review before committing.
I realized that we could limit the catalog query reuse to only
On Wed, Mar 5, 2025 at 12:13 AM Nathan Bossart wrote:
>
> On Tue, Mar 04, 2025 at 01:05:17PM +0700, John Naylor wrote:
> > On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart
> > wrote:
> >> I did that in v3. I also tried to break up this comment into bullet points
> >> for better separation and log
On Tue, Mar 04, 2025 at 01:05:17PM +0700, John Naylor wrote:
> On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart
> wrote:
>> I did that in v3. I also tried to break up this comment into bullet points
>> for better separation and logical flow.
>
> That's much easier to follow, thanks.
Thanks for l
On Mon, Mar 3, 2025 at 11:21 PM Nathan Bossart wrote:
>
> On Mon, Mar 03, 2025 at 05:58:43PM +0700, John Naylor wrote:
> True. One small thing we could do is to require "found_objs" (the double
> pointer) to always be non-NULL, but that just compels some callers to
> provide otherwise-unused vari
On Mon, Mar 03, 2025 at 05:58:43PM +0700, John Naylor wrote:
> On Sat, Mar 1, 2025 at 3:42 AM Nathan Bossart
> wrote:
>> On Thu, Feb 27, 2025 at 04:36:04PM +0700, John Naylor wrote:
>> > I had to read it several times before I noticed the difference between
>> > "* found_objs" and "*found_objs".
On Sat, Mar 1, 2025 at 3:42 AM Nathan Bossart wrote:
>
> On Thu, Feb 27, 2025 at 04:36:04PM +0700, John Naylor wrote:
> > I had to read it several times before I noticed the difference between
> > "* found_objs" and "*found_objs". Maybe some extra spacing and breaks
> > would help, or other reorg
On Thu, Feb 27, 2025 at 04:36:04PM +0700, John Naylor wrote:
> On Wed, Feb 5, 2025 at 4:44 AM Nathan Bossart
> wrote:
>> [v2]
>
> I started looking just at 0001, and it seems like a fairly
> straightforward rearrangement.
Thanks for taking a look.
> I found this comment quite hard to read:
>
On Wed, Feb 5, 2025 at 4:44 AM Nathan Bossart wrote:
> [v2]
I started looking just at 0001, and it seems like a fairly
straightforward rearrangement. I found this comment quite hard to
read:
+ * 'found_objs' should be a fully qualified list of objects to process, as
+ * returned by a previous ca
I had the opportunity to bring this patch set up for discussion at the
developer meeting at FOSDEM PGDay last week [0]. There seemed to be a
strong consensus that the idea of a "missing only" mode for vacuumdb's
analyze options was useful (especially so if the extended stats piece of
the stats imp
On Fri, Jan 24, 2025 at 7:44 AM Nathan Bossart wrote:
>
> On Mon, Jan 06, 2025 at 03:27:18PM -0600, Nathan Bossart wrote:
> > On Mon, Dec 30, 2024 at 03:45:03PM -0500, Bruce Momjian wrote:
> >> On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
> >>> I suggest that we make a new thread ab
>
> Thoughts?
>
I don't have anything to add to what Nathan said, but thought I should say
so since this thread was broken off from my earlier thread. Eagerly
awaiting feedback.
On Mon, Jan 06, 2025 at 03:27:18PM -0600, Nathan Bossart wrote:
> On Mon, Dec 30, 2024 at 03:45:03PM -0500, Bruce Momjian wrote:
>> On Mon, Dec 30, 2024 at 12:02:47PM -0800, Jeff Davis wrote:
>>> I suggest that we make a new thread about the vacuumdb changes and
>>> focus this thread and patch seri
21 matches
Mail list logo
