On Wed, Feb 01, 2012 at 04:12:58PM -0600, Jim Nasby wrote: > On Jan 26, 2012, at 9:32 PM, Robert Haas wrote: > > But if we want to put it on a diet, the first thing I'd probably be > > inclined to lose is the float4 specialization. Some members of the > > audience will recall that I take dim view of floating point arithmetic > > generally, but I'll concede that there are valid reasons for using > > float8. I have a harder time coming up with a good reason to use > > float4 - ever, for anything you care about. So I would be inclined to > > think that if we want to trim this back a bit, maybe that's the one to > > let go. If we want to be even more aggressive, the next thing I'd > > probably lose is the optimization of multiple sortkey cases, on the > > theory that single sort keys are probably by far the most common > > practical case. > > I do find float4 to be useful, though it's possible that my understanding is > flawed… > > We end up using float to represent ratios in our database; things that > really, honest to God do NOT need to be exact. > > In most cases, 7 digits of precision (which AFAIK is what you're guaranteed > with float4) is plenty, so we use float4 rather than bloat the database > (though, since we're on 64bit hardware I guess that distinction is somewhat > moot…). > > Is there something I'm missing that would make float4 useless as compared to > float8? > -- > Jim C. Nasby, Database Architect j...@nasby.net > 512.569.9461 (cell) http://jim.nasby.net > If the values stored are float4, it would be nice to have that fast-path sort available too. The cases where I have used float4 values in the past, I absolutely did not need any of the float8 baggage and in my case, using the actual float4 comparison operator resulted in a significant time savings over the normal float8. This could be processor specific, but it would be worth testing before throwing it out.
Regards, Ken -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers