Re: Progress on fast path sorting, btree index creation time

From: Jim Nasby <jim(at)nasby(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Progress on fast path sorting, btree index creation time
Date: 2012-02-01 22:12:58
Message-ID: 49C9F616-07FD-4504-AEE5-678CDAF5C2A9@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Duncan Rance 2012-02-01 22:37:32 Re: BUG #6425: Bus error in slot_deform_tuple
Previous Message Tom Lane 2012-02-01 21:43:34 Re: BUG #6425: Bus error in slot_deform_tuple