2017-11-14 10:32 GMT+09:00 Andres Freund <and...@anarazel.de>: > On 2017-11-13 20:21:47 -0500, Tom Lane wrote: >> Kohei KaiGai <kai...@heterodb.com> writes: >> > How about your thought for support of half-precision floating point, >> > FP16 in short? >> >> This sounds like a whole lotta work for little if any gain. There's not >> going to be any useful performance gain from using half-width floats >> except in an environment where it's the individual FLOPs that dominate >> your costs. PG is not designed for that sort of high-throughput >> number-crunching, and it's not likely to get there anytime soon. >> >> When we can show real workloads where float32 ops are actually the >> dominant time sink, it would be appropriate to think about whether >> float16 is a useful solution. I don't deny that we could get there >> someday, but I think putting in float16 now would be a fine example >> of having your priorities reversed. > > Agree that there's no performance argument. I think you could kinda > sorta make an argument for higher storage density in cases where a lot > of floats are stored in the database. I'd personally still consider > that not worthwhile to invest time in, but ... > Yes. I don't think PostgreSQL will perform massive calculation intensive workloads by itself. (If people want, we have PL/CUDA to run advanced algorithms in UDF, as an aside.) However, data management is a top priority job for DBMS, and storage density directly affects to the performance to load data stream onto multicore processors (like GPUs).
My proposition intends to reduce storage/memory consumption when user stores massive amount of floating point arrays database. Thanks, -- HeteroDB, Inc / The PG-Strom Project KaiGai Kohei <kai...@heterodb.com>