Re: [HACKERS] PostgreSQL Tuning Results

>
>
>Actually, the results are completely expected once you know what's
>exactly is going on. I found it weird that my sorts were also slowing
>down with more sort memory until Tom or Bruce or someone pointed out to
>me that my stats said my sorts were swapping.
>
>

this way my first expectation but since the machine was newly booted and
had 1/2 gig of ram (nothing running but PostgreSQL) I couldn't believe
in that theory ...
Maybe but I couldn't verify that ...
Of course swapping is worse than anything else.

>This strikes me, too, as another area where mmap might allow the system
>to do a better job with less tuning. Basically, the sort is getting
>split into a bunch of smaller chunks, each of which is individually
>sorted, and then you merge at the end, right? So if all those individual
>chunks were mmaped, the system could deal with paging them out if and
>when necessary, and for the sorts you do before the merge, you could
>mlock() the area that you're currently sorting to make sure that it
>doesn't thrash.
>

As far as I have seen in the source code they use Knuth's tape
algorithm. It is based on dividing, sorting, and merging together.

>If the VM system accepts hints, you might also get some further
>optimizations because you can tell it (using madvise()) when you're
>doing random versus sequential access on a chunk of memory.
>
>cj
>

it is an interesting topic. the result of the benchmark is very clock
speed depedent (at least in case my of my data structure).

Hans

--
Cybertec Geschwinde &. Schoenig
Ludo-Hartmannplatz 1/14; A-1160 Wien
Tel.: +43/1/913 68 09 oder +43/664/233 90 75
URL: www.postgresql.at, www.cybertec.at, www.python.co.at, www.openldap.at