Re: Inlining comparators as a performance optimisation

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

To: Peter Geoghegan <peter@2ndquadrant.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, PG Hackers <pgsql-hackers@postgresql.org>

Date: 2011-09-21T14:31:11Z

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

On 21.09.2011 17:20, Peter Geoghegan wrote:
> Even still, I
> think that the 12.5% figure is pretty pessimistic - I've already sped
> up the dell store query by almost that much, and that's with a patch
> that was, due to circumstances, cobbled together.

I'm not against making things faster, it's just that I haven't seen 
solid evidence yet that this will help. Just provide a best-case test 
case for this that shows a huge improvement, and I'll shut up. If the 
improvement is only modest, then let's discuss how big it is and whether 
it's worth the code ugliness this causes.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com