Re: Statistics Import and Export - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Statistics Import and Export
Date
Msg-id e0660898b696b0bb77030f8b850d662ad3c663d2.camel@j-davis.com
Whole thread Raw
In response to Re: Statistics Import and Export  (jian he <jian.universality@gmail.com>)
List pgsql-hackers
On Mon, 2024-09-23 at 08:57 +0800, jian he wrote:
>     newtup = heap_modify_tuple_by_cols(ctup, tupdesc, ncols,
> replaces, nulls);
>
> you just directly declared "bool nulls[3]    = {false, false,
> false};"

Those must be false (not NULL), because in pg_class those are non-NULL
attributes. They must be set to something whenever we update.

> if any of (RELPAGES_ARG, RELTUPLES_ARG, RELALLVISIBLE_ARG)
> is null, should you set that null[position] to true?

If the corresponding SQL argument is NULL, we leave the existing value
unchanged, we don't set it to NULL.

> otherwise, i am confused with the variable nulls.
>
> Looking at other usage of heap_modify_tuple_by_cols, "ncols" cannot
> be
> dynamic, it should be a fixed value?
> The current implementation works, because the (bool[3] nulls) is
> always false, never changed.
> if nulls becomes {false, false, true} then "ncols" must be 3, cannot
> be 2.

heap_modify_tuple_by_cols() uses ncols to specify the length of the
values/isnull arrays. The "replaces" is an array of attribute numbers
to replace (in contrast to plain heap_modify_tuple(), which uses an
array of booleans).

We are going to replace a maximum of 3 attributes, so the arrays have a
maximum size of 3. Predeclaring the arrays to be 3 elements is just
fine even if we only use the first 1-2 elements -- it avoids a needless
heap allocation/free.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Avoid mixing custom and OpenSSL BIO functions
Next
From: Masahiko Sawada
Date:
Subject: Re: Missing deconstruct_array_builtin usage