On Tue, Nov 22, 2011 at 11:41 PM, Bruce Momjian wrote:
> Amitabh Kant wrote:> >
> >
> > On a slightly unrelated note, you had once (
> > http://archives.postgresql.org/pgsql-general/2011-08/msg00944.php) said
> to
> > limit shared_buffers max to 8 GB on Linux and leave the rest for OS
> > caching
Amitabh Kant wrote:
> > The whole memorys speed topic is also much more complicated than any
> > simple explanation can cover. How many banks of RAM you can use
> > effectively changes based on the number of CPUs and associated chipset too.
> > Someone just sent me an explanation recently of why
Greg Smith wrote:
> The whole memorys speed topic is also much more complicated than any
> simple explanation can cover. How many banks of RAM you can use
> effectively changes based on the number of CPUs and associated chipset
> too. Someone just sent me an explanation recently of why I was s
On Fri, Nov 18, 2011 at 3:39 PM, Greg Smith wrote:
> On 11/17/2011 10:44 PM, CSS wrote:
>
>> Is there any sort of simple documentation on the query planner that might
>> cover how things like increased RAM could impact how a query is executed?
>>
>
> There is no *simple* documentation on any part
On 18 Listopad 2011, 17:17, Scott Marlowe wrote:
> On Fri, Nov 18, 2011 at 3:09 AM, Greg Smith wrote:
>> On 11/17/2011 10:44 PM, CSS wrote:
>>>
>>> Is there any sort of simple documentation on the query planner that
>>> might
>>> cover how things like increased RAM could impact how a query is
>>>
On Fri, Nov 18, 2011 at 3:09 AM, Greg Smith wrote:
> On 11/17/2011 10:44 PM, CSS wrote:
>>
>> Is there any sort of simple documentation on the query planner that might
>> cover how things like increased RAM could impact how a query is executed?
>
> There is no *simple* documentation on any part of
On 11/17/2011 10:44 PM, CSS wrote:
Is there any sort of simple documentation on the query planner that
might cover how things like increased RAM could impact how a query is
executed?
There is no *simple* documentation on any part of the query planner
that's also accurate. Query planning is i
On 18-11-2011 4:44 CSS wrote:
Resurrecting this long-dormant thread...
Btw, the 5500 and 5600 Xeons are normally more efficient with a multiple of 6
ram-modules, so you may want to have a look at 24GB (6x4), 36GB (6x4+6x2) or
48GB (12x4 or 6x8) RAM.
Thanks - I really had a hard time wrappi
Resurrecting this long-dormant thread...
On Oct 14, 2011, at 6:41 AM, Arjen van der Meijden wrote:
> On 14-10-2011 10:23, CSS wrote:
>> -I'm calling our combined databases at 133GB "small", fair
>> assumption? -Is there any chance that a server with dual quad core
>> xeons, 32GB RAM, and 2 or 4
On 14-10-2011 10:23, CSS wrote:
-I'm calling our combined databases at 133GB "small", fair
assumption? -Is there any chance that a server with dual quad core
xeons, 32GB RAM, and 2 or 4 SSDs (assume mirrored) could be slower
than the 4 old servers described above? I'm beating those on raw
cpu,
Hello all,
I've spent some time looking through previous posts regarding
postgres and SSD drives and have also been reading up on the
subject of SSDs in general elsewhere.
Some quick background:
We're currently looking at changing our basic database setup as we
migrate away from some rather old
11 matches
Mail list logo
