Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Дата
Msg-id 20210527032105.xistjgattubmjymm@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Move pg_attribute.attcompression to earlier in struct for reduced size?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2021-05-26 22:43:42 -0400, Tom Lane wrote:
> The memsets seem to be easy to get rid of.  memset the array
> to zeroes *once* before entering the per-tuple loop.  Then,
> in the loop that looks for stuff to pfree, reset any entries
> that are found to be set, thereby returning the array to all
> zeroes for the next iteration.

> I"m having a hard time though believing that the memset is the
> main problem.  I'd think the pfree search loop is at least as
> expensive.  Maybe skip that when not useful, by having a single
> bool flag remembering whether any columns got detoasted in this
> row?

Yea, I tested that - it does help in the integer case. But the bigger
contributors are the loop over the attributes, and especially the access
to the datum's compression method. Particularly the latter seems hard to
avoid.

Greetings,

Andres Freund



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

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Fdw batch insert error out when set batch_size > 65535
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Decoding speculative insert with toast leaks memory