I'm trying to figure out what I need to do to get my postgres server
moving faster. It's just crawling right now. It's on a p4 HT with 2
gigs of mem.
I was thinking I need to increase the amount of shared buffers, but
I've been told the sweet spot for shared_buffers is usually on the
order of
On Wed, 20 Oct 2004 01:33:16 +0100, Simon Riggs [EMAIL PROTECTED] wrote:
and using what version of PostgreSQL are you using? 8.0beta, I hope?
I'm using version 7.4.5.
I was thinking I need to increase the amount of shared buffers, but
I've been told the sweet spot for shared_buffers is
On Wed, 20 Oct 2004 00:35:31 -0400, Tom Lane [EMAIL PROTECTED] wrote:
I suspect that fooling with shared_buffers is entirely the wrong tree
for you to be barking up. My suggestion is to be looking at individual
queries that are slow, and seeing how to speed those up. This might
involve
On Tue, 19 Oct 2004 22:23:24 -0700, Josh Berkus [EMAIL PROTECTED] wrote:
There have been issues with Postgres+HT, especially on Linux 2.4. Try
turning HT off if other tuning doesn't solve things.
Otherwise, see:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
How would I turn
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm assuming this is probably due to
disk io.
I need some help setting up
On 5/26/05, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm
Few mandatory questions:
1. Do you vacuum your db on regular basis? :)
It's vacuumed once every hour. The table sizes and data are constantly changing.
2. Perhaps statistics for tables in question are out of date, did you
try alter table set statistics?
No I haven't. What would that
I think you really want that seqscan to be an indexscan, instead.
I'm betting this is PG 7.4.something? If so, probably the only
way to make it happen is to simplify the now() expression to a constant:
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM
=4)
Filter: ((tstamp)::text ((now() - '00:05:00'::interval))::text)
Still not an index scan.
On 5/27/05, Tom Lane [EMAIL PROTECTED] wrote:
Josh Close [EMAIL PROTECTED] writes:
this_sQuery := \'
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM
I didn't see iostat as available to install, but I'm using dstat to see this.
The server has constant disk reads averaging around 50M and quite a
few in the 60M range. This is when selects are being done, which is
almost always. I would think if postgres is grabbing everything from
memory that
On 5/31/05, Martin Fandel [EMAIL PROTECTED] wrote:
In the documentation of
http://www.powerpostgresql.com/Downloads/annotated_conf_80.html
is the shared_buffers set to 1/3 of the availble RAM. You're set
5*8/1024=391 MB SHMEM. The effective_cache_size in your
configuration is
On 6/8/05, Francisco Figueiredo Jr. [EMAIL PROTECTED] wrote:
--- Josh Close [EMAIL PROTECTED] escreveu:
Well, that would make total sense. I was kinda curious how the data
provider differentianted between :a and casting like now()::text.
Hi Josh!
Npgsql uses the info found
12 matches
Mail list logo
