| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |
| Date: | 2021-05-27 03:21:05 |
| Message-ID: | 20210527032105.xistjgattubmjymm@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2021-05-27 03:32:18 | Re: Decoding speculative insert with toast leaks memory |
| Previous Message | houzj.fnst@fujitsu.com | 2021-05-27 03:12:16 | RE: Fdw batch insert error out when set batch_size > 65535 |