Re: Progress on fast path sorting, btree index creation time
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Jim Nasby <jim@nasby.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <peter@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-02T01:30:18Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
During btree index build, sort equal-keyed tuples according to their
- fbac1272b89b 8.0.0 cited
Excerpts from Jim Nasby's message of mié feb 01 19:12:58 -0300 2012: > 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. But then, do you sort using those ratios? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support