Re: properly sizing attnums in pg_get_publication_tables

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: properly sizing attnums in pg_get_publication_tables
Дата
Msg-id 20230113192626.GZ9837@telsasoft.com
обсуждение исходный текст
Ответ на properly sizing attnums in pg_get_publication_tables  (Ted Yu <yuzhihong@gmail.com>)
Список pgsql-hackers
On Fri, Jan 13, 2023 at 07:37:29AM -0800, Ted Yu wrote:
> Hi,
> I was looking at commit b7ae03953690a1dee455ba3823cc8f71a72cbe1d .
> 
> In `pg_get_publication_tables`, attnums is allocated with size
> `desc->natts`. However, since some columns may be dropped, this size may be
> larger than necessary.
> When `nattnums > 0` is false, there is no need to allocate the `attnums`
> array. In the current formation, `attnums` should be freed in this scenario.
> 
> Please take a look at the patch which moves the allocation to inside the
> `if (nattnums > 0)` block.
> 
> Thanks

It doesn't seem worth the bother of changing it or adding 10 lines of
code, or keeping track of whether "attnums" is initialized or not.

After all, it wasn't worth pfree()ing the array (which seems to work as
intended).  The array can't be larger than ~3200 bytes, and I doubt
anybody is going to be excited about saving a couple bytes per dropped
column.

-- 
Justin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: Transaction timeout
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?