Re: Remove configure --disable-float4-byval and --disable-float8-byval
| От | Tom Lane |
|---|---|
| Тема | Re: Remove configure --disable-float4-byval and --disable-float8-byval |
| Дата | |
| Msg-id | 15314.1572631210@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Remove configure --disable-float4-byval and --disable-float8-byval (Peter Geoghegan <pg@bowt.ie>) |
| Ответы |
Re: Remove configure --disable-float4-byval and --disable-float8-byval
Re: Remove configure --disable-float4-byval and--disable-float8-byval |
| Список | pgsql-hackers |
Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Nov 1, 2019 at 7:41 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> Could we get around this by making Datum 8 bytes everywhere?
> I really like that idea.
> Even Raspberry Pi devices (which can cost as little as $35) use 64-bit
> ARM processors. It's abundantly clear that 32-bit platforms do not
> matter enough to justify keeping all the SIZEOF_DATUM crud around.
This line of argument seems to me to be the moral equivalent of
"let's drop 32-bit support altogether". I'm not entirely on board
with that. Certainly, a lot of the world is 64-bit these days,
but people are still building small systems and they might want
a database; preferably one that hasn't been detuned to the extent
that it barely manages to run at all on such a platform. Making
a whole lot of internal APIs 64-bit would be a pretty big hit for
a 32-bit platform --- more instructions, more memory consumed for
things like Datum arrays, all in a memory space that's not that big.
It seems especially insane to conclude that we should pull the plug
on such use-cases just to get rid of one obscure configure option.
If we were expending any significant devel effort on supporting
32-bit platforms, I might be ready to drop support, but we're not.
(Robert's proposal looks to me like it's actually creating new work
to do, not saving work.)
regards, tom lane
В списке pgsql-hackers по дате отправления: