vacuum analyze on the table repcopy
In addition to that, indexes on report_time, report_status, and dm_user
might help.
And your query is not "hung", it's just taking a LONG time. Based
on the explain, it could take several hours to complete. How many
rows are in repcopy? What is your vacuum schedule? Do a vacuum verbose,
if the number of dead rows is very high on that table, you may benefit
from doing a VACUUM FULL + REINDEX or CLUSTER on the table.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
probably start working.
* You _may_ be able to get the application to start working without
granting superuser privs, simply by setting the value of log_statement
to "none" in the postgresql.conf. This is assuming the application is
smart enough to check the value and only
ent sized blocks of data."
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Bill Moran
> Sent: Thursday, April 26, 2007 3:32 PM
> To: Sorin N. Ciolofan
> Cc: [EMAIL PROTECTED]; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] [
ble with,
reduce the shared_buffers setting in the config. That will allow the OS
to decide how to use the memory instead.
--
Bill Moran
http://www.potentialtech.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore y
Is there any way to know at a certain moment with precision how much shared
> memory expressed in Mb is used?
The precision is +/- 1 buffer. I expect that trying to get more precision out
of the system will result in considerable performance degradation as the
data is collected and/or tracked.
--
Bill Moran
http://www.potentialtech.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
art of the contrib directory that ships with the source tarball.
Depending on your OS and associated packaging system (which you don't
bother to mention) it's probably available via RPMs or DEBs or whatever.
For example, under FreeBSD it's in /usr/ports/databases/post
ection heavy transaction
> processing database: 240MB/3
> * Quad Xeon server, 8GB RAM, 200GB, 300-connection heavy transaction
> processing database: 400MB/5
>
> Please note that increasing shared_buffers, and a few other memory
> parameters, will require you to modif
nstalled might have done so.
However, on more recent versions of Postgres (although I don't know exactly
what version first included this) you can specify this value as "M" or "G"
to specify a number of megabytes or gigabytes. Internally, this is still
converted to a numb
autovac, you may want to experiment with
vacuum_cost_delay and associated parameters, which can lessen the
impact of vacuuming.
--
Bill Moran
Collaborative Fusion Inc.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send
Tom Lane wrote:
Bill Moran <[EMAIL PROTECTED]> writes:
curious about some things, so I set shared_buffers to 16 (which the
config file claims is the lowest allowable value) The result was
that Postgre refused to start. I upped it to 32 and the result
was the same.
I looked in both /v
7;t sure which one
was wrong)
TIA for answers.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
11 matches
Mail list logo
