Re: Multiple Indexing, performance impact - Mailing list pgsql-general

From Daniel Åkerud
Subject Re: Multiple Indexing, performance impact
Date
Msg-id 003e01c0fb5c$812e44b0$c901a8c0@automatic100
Whole thread Raw
In response to Multiple Indexing, performance impact  (Daniel Åkerud <zilch@home.se>)
Responses Re: Multiple Indexing, performance impact  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-general
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
>


pgsql-general by date:

Previous
From: "Thalis A. Kalfigopoulos"
Date:
Subject: Re: Re[4]: Postgres is too slow?
Next
From: Alex Pilosov
Date:
Subject: Re: Re[4]: Postgres is too slow?