Re: [PERFORM] A Better External Sort?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PERFORM] A Better External Sort?
Дата
Msg-id 7788.1128434784@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PERFORM] A Better External Sort?  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: [PERFORM] A Better External Sort?  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: \d on database with a lot of tables is slow
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: pg_dump versioning