From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AIX support - alignment issues |
Date: | 2022-07-06 17:17:24 |
Message-ID: | CA+TgmobgUDZUQM=ypRvuBS1UuQamk3J9wQbA6FPu=t6SywiyoA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 6, 2022 at 12:27 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think my proposal of introducing a version of double that is marked to be 8
> byte aligned should do the trick as well, and doesn't have the problem of
> changing the meaning of 'double' references in external headers. In fact, we
> already have float8 as a type, so we could just add it there.
Yeah, but how easily will it be to know whether we've used that in
every relevant place?
Could we insist on 8-byte alignment even on 32-bit platforms? I think
we have a few of those in the buildfarm, so maybe that would help us
spot problems. Although I'm not sure how, exactly.
> The problem with having a lot more alignment values is that it adds a bunch of
> overhead to very performance critical paths. We don't want to add more
> branches to att_align_nominal() if we can avoid it.
Fair.
> I'm fairly certain that we're going to add a lot more 64bit ints to catalogs
> in the next few years, so this will become a bigger issue over time...
Absolutely.
> Outside of the catalogs I still think that we should work towards not aligning
> byval values (and instead memcpy-ing the values to deal with alignment
> sensitive platforms), so we don't waste so much space. And for catalogs we've
> been talking about giving up the struct mapping as well, in the thread about
> variable length names. In which case we could the cost of handling more
> alignment values wouldn't be incurred as frequently.
+1. Aligning stuff on disk appears to have few redeeming properties
for the amount of pain it causes.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2022-07-06 17:23:52 | Re: doc: Move enum storage commentary to top of section |
Previous Message | Robert Haas | 2022-07-06 17:11:07 | Re: Possible fails in pg_stat_statements test |