| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 02:24:12 |
| Message-ID: | 20210527022412.kqujhfeblutq6cfm@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-05-27 11:07:53 +0900, Michael Paquier wrote:
> This depends on the number of attributes, but I do see an extra 0.5%
> __memmove_avx_unaligned_erms in reform_and_rewrite_tuple() for a
> normal VACUUM FULL with a 1-int-column relation on a perf profile,
> with rewrite_heap_tuple eating most of it as in the past, so that's
> within the noise bandwidth if you measure the runtime.
> What would be the worst case here, a table with one text column made
> of non-NULL still very short values?
I think you need a bunch of columns to see it, like in the benchmark I
just posted - I didn't test any other number of columns than 10 though.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2021-05-27 02:29:43 | Re: Speed up pg_checksums in cases where checksum already set |
| Previous Message | tsunakawa.takay@fujitsu.com | 2021-05-27 02:18:16 | RE: Parallel Inserts in CREATE TABLE AS |