Re: Multiple Indexing, performance impact

Holy ultra-violet-active macaronies :)

First I changed it to 256, then I changed it to 1024.

-B 128 is A
-B 256 is B
-B 1024 is C

New multiple-index performance data):

1.    A: 36    B: 32    C: 35
2.    A: 69    B: 53    C: 38
3.    A: 97    B: 79    C: 40
4.    A: 131    B: 98    C: 48
5.    A: 163    B: 124    C: 52
6.    A: 210    B: 146    C: 66
7.    A: 319    B: 233    C: 149
8.    A: 572    B: 438    C: 268
9.    A: 831    B: 655    C:
10.    A: 1219    B: 896    C:

The last test hasn't finished yet, but THANKS! I know the reson now, at
least... i'll try
2048 also.

-B equals --brutal-performance ? ;)

Thanks,
Daniel Åkerud

> That should be enough to see if there's a performance change, but for
> future reference, yes you should go higher.  On modern machines with
> many megs of RAM, you should probably be using -B on the order of a few
> thousand, at least for production installations.  The reason the default
> is so low is that we hope the system will still be able to fire up on
> machines where the kernel enforces a SHMMAX limit of only a meg or so.
> This hope is possibly in vain anymore anyway, since the system's
> non-buffer shared-memory usage keeps creeping up; I think 7.1 is well
> past 1MB shmem even with 64 buffers...
>
> regards, tom lane
>