Re: Progress on fast path sorting, btree index creation time
От | Jim Nasby |
---|---|
Тема | Re: Progress on fast path sorting, btree index creation time |
Дата | |
Msg-id | 49C9F616-07FD-4504-AEE5-678CDAF5C2A9@nasby.net обсуждение исходный текст |
Ответ на | Re: Progress on fast path sorting, btree index creation time (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Progress on fast path sorting, btree index creation time
Re: Progress on fast path sorting, btree index creation time |
Список | 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 ratherthan 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@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: