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
>