Re: [PERFORM] A Better External Sort?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Ron Peacetree <rjpeace(at)earthlink(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PERFORM] A Better External Sort?
Date: 2005-10-04 14:06:24
Message-ID: 7788.1128434784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> A quick binary search puts the cutoff between 1200 and 1300. Given
> version variation I picked a nice round number, 1500.

> Ugh, that's for -O2, for -O3 and above it needs to be 4100 to work.
> Maybe we should go for 5000 or so.

> I'm using: gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

I don't know what the units of this number are, but it's apparently far
too gcc-version-dependent to consider putting into our build scripts.
Using gcc version 4.0.1 20050727 (current Fedora Core 4 compiler) on
i386, and compiling tuplesort.c as you did, I find:
-O2: warning goes away between 800 and 900
-O3: warning is always there (tried values up to 10000000)
(the latter behavior may indicate a bug, not sure).

What's even more interesting is that the warning does not appear in
either case if I omit -finline-limit --- so the default value is plenty.

At least on this particular compiler, the proposed switch would be
counterproductive.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-04 14:17:27 Re: memory bug debugging
Previous Message Tom Lane 2005-10-04 13:52:58 Re: New pg_config behavior

Browse pgsql-performance by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-10-04 14:30:42 Re: [PERFORM] A Better External Sort?
Previous Message Martijn van Oosterhout 2005-10-04 12:24:46 Re: [PERFORM] A Better External Sort?