Am 27.11.2006 um 08:04 schrieb Guido Neitzer:
But, be aware of another thing here: As far as I have read about 64
Bit applications on G5, these apps are definitely slower than their
32 bit counterparts (I'm currently on the train so I can't be more
precise here without Google ...). Was it s
On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
It certainly is unfortunate if Guido's right and this is an upper
limit for OS X. The performance benefit of having high shared_buffers
on our mostly read database is remarkable.
Got any
Am 27.11.2006 um 00:25 schrieb Jim C. Nasby:
Got any data about that you can share? People have been wondering
about
cases where drastically increasing shared_buffers makes a difference.
I have tried to compile PostgreSQL as a 64Bit application on my G5
but wasn't successful. But I must ad
Am 27.11.2006 um 04:20 schrieb Brendan Duddridge:
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
We have 8 GB of RAM on that server, but we can't seem to utilize it
all. At least not for the shared_buffers se
On 27-Nov-06, at 4:04 AM, Tom Lane wrote:
Brendan Duddridge <[EMAIL PROTECTED]> writes:
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
There is no obvious reason why it would not work, and if anyone has
tried an
Brendan Duddridge <[EMAIL PROTECTED]> writes:
> I think the main issue is that we can't seem to get PostgreSQL
> compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
There is no obvious reason why it would not work, and if anyone has
tried and failed, they've not bothered to provid
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
We have 8 GB of RAM on that server, but we can't seem to utilize it
all. At least not for the shared_buffers setting.
Thanks,
__
On Sun, Nov 26, 2006 at 12:24:17PM +0100, Joost Kraaijeveld wrote:
> Hi,
>
> Are there guidelines (or any empirical data) available how to determine
> how often a table should be vacuumed for optimum performance or is this
> an experience / trial-and-error thing?
Most of the time I just turn auto
On Thu, Nov 23, 2006 at 03:40:15PM -0500, Brad Nicholson wrote:
> On Tue, 2006-11-21 at 21:43 -0200, Carlos H. Reimer wrote:
> > Hi,
> >
> > We have an application that is mission critical, normally very fast,
> > but when an I/O or CPU bound transaction appears, the mission critical
> > applicat
On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote:
> ...I read a large number of articles on this subject and am
> absolutely dumbfounded by the -ahem- idiots who think killing a random
> process is an appropriate action. I'm just taking their word for it that
> there's some kind of imp
On Wed, Nov 22, 2006 at 04:35:37PM -0500, Bucky Jordan wrote:
> While I'm at it, if I have time I'll run pgbench with pg_log on a
> separate RAID1, and one with it on a RAID10x6, but I don't know how
> useful those results will be.
Very, but only if the controller has write-caching enabled. For te
On Wed, Nov 22, 2006 at 09:02:04AM -0800, Jeff Frost wrote:
> A valid question. Does the caching raid controller negate the desire to
> separate pg_xlog from PGDATA?
Theoretically, yes. But I don't think I've seen any hard numbers from
testing.
--
Jim Nasby
On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
> It certainly is unfortunate if Guido's right and this is an upper
> limit for OS X. The performance benefit of having high shared_buffers
> on our mostly read database is remarkable.
Got any data about that you can share? People hav
If you really want to know, read the mountains of (mostly) junk that
have been written about replacing VACUUM in pgsql-hackers. The short
answer (with apologies to Winston Churchill) is that VACUUM is the worst
solution, except for all the others that have been suggested.
The lesser of 50 evi
"Craig A. James" <[EMAIL PROTECTED]> writes:
> Is there no real-time garbage collection at all in Postgres?
No.
> And if so, is this because nobody has had time to implement garbage
> collection, or for a more fundamental reason, or because VACUUM is
> seen as sufficient?
If you really want to k
Rod Taylor wrote:
Just a minor clarification here: INSERT does not create dead rows, only
UPDATE and DELETE do. Thus, if you only insert rows, you do not need to
vacuum (although you probably need to analyze).
Is there no real-time garbage collection at all in Postgres? And if so, is
this bec
On Sun, Nov 26, 2006 at 09:24:29AM -0500, Rod Taylor wrote:
> attempt and fail a large number of insert transactions then you will
> still need to vacuum.
And you still need to vacuum an insert-only table sometimes, because
of the system-wide vacuum requirement.
A
--
Andrew Sullivan | [EMAI
On 26-Nov-06, at 8:11 AM, Steinar H. Gunderson wrote:
On Sun, Nov 26, 2006 at 09:43:11AM -0300, Marcelo Costa wrote:
All its tables constantly manipulated (INSERT, UPDATE, DELETE)
they need a
VACUUM
Just a minor clarification here: INSERT does not create dead rows,
only
UPDATE and DELETE
Sorry,
realy you are correct.
[],s
Marcelo Costa.
2006/11/26, Steinar H. Gunderson <[EMAIL PROTECTED]>:
On Sun, Nov 26, 2006 at 09:43:11AM -0300, Marcelo Costa wrote:
> All its tables constantly manipulated (INSERT, UPDATE, DELETE) they need
a
> VACUUM
Just a minor clarification here: INSER
On Sun, Nov 26, 2006 at 09:43:11AM -0300, Marcelo Costa wrote:
> All its tables constantly manipulated (INSERT, UPDATE, DELETE) they need a
> VACUUM
Just a minor clarification here: INSERT does not create dead rows, only
UPDATE and DELETE do. Thus, if you only insert rows, you do not need to
vacuu
Hi,
From: http://www.postgresql.org/docs/7.4/interactive/sql-vacuum.html
"VACUUM reclaims storage occupied by deleted tuples. In normal
PostgreSQLoperation, tuples that are deleted or obsoleted by an update
are not
physically removed from their table; they remain present until a VACUUM is
done.
Hi,
Are there guidelines (or any empirical data) available how to determine
how often a table should be vacuumed for optimum performance or is this
an experience / trial-and-error thing?
TIA
--
Groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-518
22 matches
Mail list logo
