On Tue, 2005-06-07 at 23:50 -0400, Tom Lane wrote:
> > Regarding 2GB memory allocation, though, we *could* really use support for
> > work_mem and maintenance_mem of > 2GB.
>
> Again, let's see some evidence that it's worth putting effort into that.
> (Offhand it seems this is probably an easi
Josh Berkus writes:
> Not that I've seen in testing so far. Your improvements have, fortunately,
> eliminated the penalty for allocating too much shared buffers as far as I can
> tell (at least, allocating 70,000 when gains stopped at 15,000 doesn't seem
> to carry a penalty),
Cool, that's de
Tom,
> Obviously we'd be willing to do this work if there were convincing
> evidence it'd be worth the time. A benchmark showing performance
> continuing to climb with increasing shared_buffers right up to the 2Gb
> limit would be reasonably convincing. I think there is 0 chance of
> drawing suc
Neil Conway wrote:
> Tom Arthurs wrote:
>
>> Yes, shared buffers in postgres are not used for caching
>
>
> Shared buffers in Postgres _are_ used for caching, they just form a
> secondary cache on top of the kernel's IO cache. Postgres does IO
> through the filesystem, which is then cached by th
Tom Arthurs wrote:
Yes, shared buffers in postgres are not used for caching
Shared buffers in Postgres _are_ used for caching, they just form a
secondary cache on top of the kernel's IO cache. Postgres does IO
through the filesystem, which is then cached by the kernel. Increasing
shared_buff
On Mon, 2005-06-06 at 09:48 -0700, Jone C wrote:
> HI!
>
> I have a table that I use for about a month. As the month progresses,
> COPYs performed to this table get much much slower than they were at
> the beginning, for the same number of rows (about 100,000 and
> growing).
>
> I'm essentially d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This was the standard wisdom with releases previous to 8.0; I'm not sure
> if anyone confirmed to still hold after the buffer manager changes in
> 8.0 and later in 8.1 -- we saw extensive redesign of the bufmgr on both,
> so the behavior may have changed
On Tue, Jun 07, 2005 at 01:39:04PM -0700, Tom Arthurs wrote:
Yes, shared buffers in postgres are not used for caching
That begs the question of what they are used for. :)
Mike Stone
---(end of broadcast)---
TIP 9: the planner will ignore your de
On Tue, Jun 07, 2005 at 04:19:24PM -0400, Donald Courtney wrote:
> The system has 8 CPUs w/ 32 GB - I'm hoping to see some benefit to large
> caches -
> Am I missing something key with postgreSQL?
Yeah. Postgres makes extensive use of the kernel's cache (or, more
precisely, assumes that the ke
Yes, shared buffers in postgres are not used for caching -- unlike
Oracle. Every time we hire an Oracle dba, I have to break them of the
notion (which I shared when I started with postgres -- Josh Berkus and
Josh Drake helped burst that bubble for me) :)
You should gain i/o reduction through
Tom Arthurs wrote:
According to my research, you only need a 64 bit image if you are
going to be doing intensive floating point operations (which most db
servers don't do). Some benchmarking results I've found on the
internet indicate that 64 bit executables can be slower than 32 bit
version
The system has 8 CPUs w/ 32 GB - I'm hoping to see some benefit to large
caches -
Am I missing something key with postgreSQL?
Yes - we have seen with oracle 64 bit that there can be as much as a 10%
hit moving
from 32 - but we make it up big time with large db-buffer sizes that
drastically
According to my research, you only need a 64 bit image if you are going
to be doing intensive floating point operations (which most db servers
don't do). Some benchmarking results I've found on the internet
indicate that 64 bit executables can be slower than 32 bit versions.
I've been running
Get FATAL when starting up (64 bit) with large shared_buffers setting
I built a 64 bit for Sparc/Solaris easily but I found that the
startup of postmaster generates a FATAL diagnostic due to going
over the 2GB limit (3.7 GB).
When building for 64 bit is there some other
things that must change
John A Meinel wrote:
Isn't this actually more of a problem for the meta-data to give out in a
hardware situation? I mean, if the card you are using dies, you can't
just get another one.
With software raid, because the meta-data is on the drives, you can pull
it out of that machine, and put it in
My tests included using aqua studios connection to both databases and
.asp
page using odbc connections.
Performance also depends a lot on the driver.
For instance, the PHP driver for MySQL is very very fast. It is also very
dumb, as it returns everything as a string and doesn't kn
On Thu, 2 Jun 2005 06:19 am, Casey Allen Shobe wrote:
> I found this response to my original post, and tried every single suggestion
> in it, which has not helped:
>
> http://archives.postgresql.org/pgsql-performance/2004-11/msg00416.php
>
> I'm sorry to come begging for help, but this is a MAJO
17 matches
Mail list logo
