[Jim C. Nasby - Thu at 11:31:26AM -0500]
> The issue with pg_xlog is you don't need bandwidth... you need super-low
> latency. The best way to accomplish that is to get a battery-backed RAID
> controller that you can enable write caching on. In fact, if the
> controller is good enough, you can theo
> I just came to think about /proc/sys/swappiness ...
>
> When this one is set to a high number (say, 100 - which is maximum), the
> kernel will aggressively swap out all memory that is not beeing
> accessed, to allow more memory for caches. For a postgres server, OS
> caches are good, because po
[Ron - Thu at 03:10:35PM -0400]
> Jim is correct that traditional 7.x folklore regarding shared buffer
> size is nowhere near as valid for 8.x. Jim tends to know what he is
> talking about when speaking about pg operational issues.
I would not doubt it, but it's always better to hear it from mo
On 10/19/06, Ron <[EMAIL PROTECTED]> wrote:
Nonetheless, "YMMV". The only sure way to know what is best for your
SW running on your HW under your load conditions is to test, test, test.
anybody have/know of some data on shared buffer settings on 8.1+?
merlin
---(end o
At 12:35 PM 10/19/2006, Tobias Brox wrote:
[Jim C. Nasby - Thu at 10:28:31AM -0500]
> I think it'd be much better to experiment with using much larger
> shared_buffers settings. The conventional wisdom there is from 7.x days
> when you really didn't want a large buffer, but that doesn't really
>
[Jim C. Nasby - Thu at 12:00:39PM -0500]
> Well, if you're buying unreliable hardware, there's not much you can
> do... you're setting yourself up for problems.
I'm luckily not responsible for the hardware, but my general experience
tells that you never know anything about hardware reliability unt
[Jim C. Nasby - Thu at 12:00:39PM -0500]
> What's reasonable for work_mem depends on your workload. If you've got
> some reporting queries that you know aren't run very concurrently they
> might benefit from large values of work_mem. For stats.distributed.net,
> I set work_mem to something like 2MB
On Thu, Oct 19, 2006 at 06:53:49PM +0200, Tobias Brox wrote:
> [Jim C. Nasby - Thu at 11:45:32AM -0500]
> > > > The issue with pg_xlog is you don't need bandwidth... you need super-low
> > > > latency. The best way to accomplish that is to get a battery-backed RAID
> > > > controller that you can e
[Jim C. Nasby - Thu at 11:45:32AM -0500]
> > > The issue with pg_xlog is you don't need bandwidth... you need super-low
> > > latency. The best way to accomplish that is to get a battery-backed RAID
> > > controller that you can enable write caching on.
> >
> > Sounds a bit risky to me :-)
>
> We
On Thu, Oct 19, 2006 at 06:39:22PM +0200, Tobias Brox wrote:
> [Jim C. Nasby - Thu at 11:31:26AM -0500]
> > Yeah, test setups are a good thing to have...
>
> We would need to replicate the production traffic as well to do reliable
> tests. Well, we'll get to that one day ...
Marginally reliable
[Jim C. Nasby - Thu at 11:31:26AM -0500]
> Yeah, test setups are a good thing to have...
We would need to replicate the production traffic as well to do reliable
tests. Well, we'll get to that one day ...
> The issue with pg_xlog is you don't need bandwidth... you need super-low
> latency. The b
[Jim C. Nasby - Thu at 10:28:31AM -0500]
> I think it'd be much better to experiment with using much larger
> shared_buffers settings. The conventional wisdom there is from 7.x days
> when you really didn't want a large buffer, but that doesn't really
> apply with the new buffer management we got i
On Thu, Oct 19, 2006 at 06:00:54PM +0200, Tobias Brox wrote:
> [Jim C. Nasby - Thu at 10:28:31AM -0500]
> > I think it'd be much better to experiment with using much larger
> > shared_buffers settings. The conventional wisdom there is from 7.x days
> > when you really didn't want a large buffer, bu
[Jim C. Nasby - Thu at 10:28:31AM -0500]
> I think it'd be much better to experiment with using much larger
> shared_buffers settings. The conventional wisdom there is from 7.x days
> when you really didn't want a large buffer, but that doesn't really
> apply with the new buffer management we got i
On Thu, Oct 19, 2006 at 03:54:28PM +0200, Tobias Brox wrote:
> I just came to think about /proc/sys/swappiness ...
>
> When this one is set to a high number (say, 100 - which is maximum), the
> kernel will aggressively swap out all memory that is not beeing
> accessed, to allow more memory for cac
I just came to think about /proc/sys/swappiness ...
When this one is set to a high number (say, 100 - which is maximum), the
kernel will aggressively swap out all memory that is not beeing
accessed, to allow more memory for caches. For a postgres server, OS
caches are good, because postgres relie
16 matches
Mail list logo
