Re: Inlining comparators as a performance optimisation
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Stark <stark@mit.edu>, Andrew Dunstan <andrew@dunslane.net>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2011-10-05T01:49:40Z
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 →
-
Speed up conversion of signed integers to C strings.
- 4fc115b2e981 9.1.0 cited
-
Remove some unnecessary tests of pgstat_track_counts.
- f4d242ef9473 9.1.0 cited
-
Remove cvs keywords from all files.
- 9f2e21138693 9.1.0 cited
-
Code cleanup for function prototypes: change two K&R-style prototypes
- b9954fbb4ef2 8.3.0 cited
-
Use Min() instead of min() in qsort, for consistency and to avoid
- b38900c76776 8.2.0 cited
-
pgindent run for 8.2.
- f99a569a2ee3 8.2.0 cited
-
Switch over to using our own qsort() all the time, as has been proposed
- 6edd2b4a91bd 8.2.0 cited
Peter Geoghegan wrote: > On the subject of highly ambitious optimisations to sorting, one > possibility I consider much more practicable than GPU-accelerated > sorting is simple threading; quicksort can be parallelised very > effectively, due to its divide-and-conquer nature. If we could agree > on a threading abstraction more sophisticated than forking, it's > something I'd be interested in looking at. To do so would obviously > entail lots of discussion about how that relates to whatever way we > eventually decide on implementing parallel query, and that's obviously > a difficult discussion. I agree that the next big challenge for Postgres is parallel operations. With the number of cores increasing, and with increased memory and SSD, parallel operation is even more important. Rather than parallelizing the entire backend, I imagine adding threading or helper processes for things like sorts, index scans, executor nodes, and stored procedure languages. I expect final code to be 2-3 years in the future. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +