> -Original Message-
> From: Andrew Sullivan [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 13, 2004 9:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Quad Xeon vs. Dual Itanium
>
>
> On Fri, Feb 13, 2004 at 10:46:18PM -0500, Tom Lane wrote:
>
> > Quite honestly, I suspect we
On Fri, Feb 13, 2004 at 10:46:18PM -0500, Tom Lane wrote:
> Quite honestly, I suspect we may be wasting our time hacking the
> Postgres buffer replacement algorithm at all. There are a bunch of
> reasons why the PG shared buffer arena should never be more than a
> small fraction of physical RAM,
On Fri, Feb 13, 2004 at 06:11:08PM -0800, Dann Corbit wrote:
>
> Size of the database is huge (e.g. every toll paid in New Jersey in the
> last 5 years)
> Available memory is huge (e.g. you buy a machine with 24 gigs of ram)
> Data bus bandwidth is huge (e.g. You buy an 8-way Opteron with 40 GB/se
Should have mentioned : assuming you are on a platform where you *have*
a choice about compilation word-length!
(Solaris and ?)
Mark Kirkwood wrote:
Now suppose you want to run a Pg database for such a situation may
as well compile 32-bit.
---(end of broadcas
No disagreement from me about the 64-bit *hardware* and *os*...
Now suppose you want to run a Pg database for such a situation may
as well compile 32-bit.
Why ? well you *dont* want to set shared_buffers to 20G... in fact 200M
works better -
why ? well your 64-bit os file cache is much more
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> So it seems to me that there is nothing to be gained using a 64-bit
> binary with the current or previous Pg releases. However, with the new
> cache replacement system being used in 7.5devel, the situation *may* be
> different (wonder if anyone has tri
> -Original Message-
> From: Mark Kirkwood [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 13, 2004 5:30 PM
> To: Andrew Sullivan
> Cc: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Quad Xeon vs. Dual Itanium
>
>
> Wouldn't you only care about 64-bit Postgres if you wanted to make
> sha
Wouldn't you only care about 64-bit Postgres if you wanted to make
shared_buffers bigger than 4G?
Various other posters have commented about the sweet-spot for
shared_buffers being ~ 100-200M (or thereabouts).
So it seems to me that there is nothing to be gained using a 64-bit
binary with the
Eric Ridge wrote:
On Feb 13, 2004, at 6:05 PM, Ron St-Pierre wrote:
I am using postgres 7.3.4 and need to be able to determine which
database a query is being run in (from a script). pg_database lists
databases but doesn't tell me which one is currently active. Is there
a query I can use along
Ron St-Pierre wrote:
I am using postgres 7.3.4 and need to be able to determine which
database a query is being run in (from a script). pg_database lists
databases but doesn't tell me which one is currently active.
See:
http://www.postgresql.org/docs/7.3/static/functions-misc.html
HTH,
Joe
---
On Feb 13, 2004, at 6:05 PM, Ron St-Pierre wrote:
I am using postgres 7.3.4 and need to be able to determine which
database a query is being run in (from a script). pg_database lists
databases but doesn't tell me which one is currently active. Is there
a query I can use along the lines of:
The
I am using postgres 7.3.4 and need to be able to determine which
database a query is being run in (from a script). pg_database lists
databases but doesn't tell me which one is currently active. Is there a
query I can use along the lines of:
UPDATE tblUpdates SET xxx=1234 WHERE pg_current = TRUE;
Rick Gigger wrote:
I am running a few web based applications with postgres on the
backend. We have a few app servers load balanced all connecting to a
dedicated postgres server. As usage on the applications increases I
want to monitor my resources so that I can anticipate when I will hit
bot
I am running a few web based applications with postgres on the backend.
We have a few app servers load balanced all connecting to a dedicated
postgres server. As usage on the applications increases I want to
monitor my resources so that I can anticipate when I will hit
bottlenecks on the db s
Does Postgres provide a builtin mechanism to
obtain the IP address of the client that is executing
the current query?
Thanks,
Iker
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comm
On Fri, 13 Feb 2004, Campano, Troy wrote:
> Hi,
> I'm trying to compare a timestamp to current_timestamp but I'm having
> trouble.
> I want to compare just the date piece of my timestamp column to just the
> date piece of current_timestamp.
>
> I'm getting weird results that I don't understand.
>
I'm using PostgreSQL 7.4.1. I have 140 clients connected on average
using libpq. When one client sends "NOTIFY timeclock;" to the server
all 140 clients are listening for it.
After receiving a notification from libpq (PQnotifies), each client
proceeds to execute a query for the last five record
On Fri, Feb 13, 2004 at 12:19:39PM -0500, Bruce Momjian wrote:
> 64-bits isn't faster than 32, and can be slower because of the longer
> pointer length, decreasing cache performance. The major advantage to
> 64-bits is accessing more the 4gb of RAM.
I note, however, that all the Sun experts say y
On Fri, Feb 13, 2004 at 01:51:24PM +, Richard Huxton wrote:
> On Friday 13 February 2004 10:59, Karsten Hilbert wrote:
> > > Well, thousands of tables is probably "too much", but a hundred tables or
> > > two in a database shouldn't cause problems. Don't see why you'd want them
> > > though.
>
19 matches
Mail list logo
