From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Peacetree <rjpeace(at)earthlink(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PERFORM] A Better External Sort? |
Date: | 2005-10-03 21:51:32 |
Message-ID: | 1128376292.8603.142.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Sun, 2005-10-02 at 21:38 +0200, Martijn van Oosterhout wrote:
> Ok, I tried two optimisations:
>
> 2. By specifying: -Winline -finline-limit-1500 (only on tuplesort.c).
> This causes inlineApplySortFunction() to be inlined, like the code
> obviously expects it to be.
>
> default build (baseline) 235 seconds
> -finline only 217 seconds (7% better)
> comparetup_index_fastbyval4 only 221 seconds (6% better)
> comparetup_index_fastbyval4 and -finline 203 seconds (13.5% better)
>
> This is indexing the integer sequence column on a 2.7 million row
> table. The times are as given by gprof and so exclude system call time.
>
> Basically, I recommend adding "-Winline -finline-limit-1500" to the
> default build while we discuss other options.
I add -Winline but get no warnings. Why would I use -finline-limit-1500?
I'm interested, but uncertain as to what difference this makes. Surely
using -O3 works fine?
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2005-10-03 21:52:27 | Re: [HACKERS] A Better External Sort? |
Previous Message | Hannu Krosing | 2005-10-03 21:43:10 | Re: [HACKERS] A Better External Sort? |
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2005-10-03 21:52:27 | Re: [HACKERS] A Better External Sort? |
Previous Message | Simon Riggs | 2005-10-03 21:47:02 | Re: [PERFORM] database bloat, but vacuums are done, and fsm seems |