On Wed, 2010-05-26 at 09:01 +0300, Mikko Partio wrote:
> With this database instance (beta1 initdb'd) I have not made
> failovers. I don't think I have any special hot standby parameters
> either.
OK, so that pretty much rules out HS as a direct cause.
> Non-default hot standby related configur
On Mon, May 24, 2010 at 10:55 PM, Simon Riggs wrote:
> On Mon, 2010-05-24 at 08:46 +0300, Mikko Partio wrote:
>
> > It was freshly initdb'd with beta1 binaries, the contents were loded
> > from a pg_dump file. The number of transactions is very small, we're
> > talking about thousands (not billio
Hi Tom and Kevin,
I stand corrected. It was awhile ago that I last played around with this. I
must have had the DELETE operation outside the transaction block back then
possibly.
Thanks for setting me straight. Sorry about the waste of time.
Sam
-Original Message-
From: Kevin Gritt
Try this:
pg_dump -a source_db | psql target_db
Sam
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Khangelani Gama
Sent: Tuesday, 25 May 2010 5:45 PM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Quickest command
Excerpts from Mitch Collinsworth's message of mar may 25 15:38:38 -0400 2010:
> On Tue, 25 May 2010, Alvaro Herrera wrote:
> > I'd say you're running 8.1, not 8.2 as initially stated.
>
> Well... yes. Sorry.I take it the answer is different then...
>
> So... How can I tell if I'm autovac
On Tue, 25 May 2010, Alvaro Herrera wrote:
Excerpts from Mitch Collinsworth's message of mar may 25 14:40:04 -0400 2010:
I'm wondering about the same question. I did the above and restarted,
and now my pg_stat_user_tables looks like this:
postgres=# \d pg_stat_user_tables
View "pg_catalog
Excerpts from Mitch Collinsworth's message of mar may 25 14:40:04 -0400 2010:
> I'm wondering about the same question. I did the above and restarted,
> and now my pg_stat_user_tables looks like this:
>
> postgres=# \d pg_stat_user_tables
> View "pg_catalog.pg_stat_user_tables"
> Column
Alex Hunsaker, thank you for your suggestion, but, the processor do not
replace OLD.TG_ARGV[1] by the content.
If I use OLD in EXECUTE it is not recognized.
I didn't get how to pass an integer variable to the trigger.
I already create repeteadly times the trigger changing the UPDATE comand
inside
On Sat, 22 May 2010, Joshua D. Drake wrote:
On Sat, 2010-05-22 at 09:51 -0400, Doug Gorley wrote:
From what I see in the docs, these three settings in postgresql.conf
should be enough for PostgreSQL (8.2) to autovacuum with the default
settings:
autovacuum = on
stats_start_collector = on
stat
On Tue, May 25, 2010 at 1:48 PM, Balkrishna Sharma wrote:
> Hi,
>
> I am increasing the shared_buffer size in postgresql.conf and want to
> measure its effect on READ. In essence I want to know if the SELECT queries
> I am firing repeatedly is reading from the buffer or going directly to the
> d
Balkrishna Sharma wrote:
> [Are there] other related parameters I should tweak as well[?]
There are several which should probably be adjusted. See:
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To m
I am on Fedora 12 (x86_64). Will eventually be on RHE.
> Date: Tue, 25 May 2010 12:59:16 -0500
> From: kevin.gritt...@wicourts.gov
> To: b...@hotmail.com; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] How to find if a SELECT is reading from buffer or
> disk ?
>
> Balkrishna Sharma
Hi,
I am having a transactional database heavy on parallel reads and updates. Apart
from hardware optimization, I want to ensure that my system parameters are
optimized as well. Following is what I am doing on my test system having 4GB
RAM. Please let me know if the logic sounds ok (at least at
Balkrishna Sharma wrote:
> I am increasing the shared_buffer size in postgresql.conf and want
> to measure its effect on READ. In essence I want to know if the
> SELECT queries I am firing repeatedly is reading from the buffer
> or going directly to the disk.
There's a third option -- PostgreS
Hi,
I am increasing the shared_buffer size in postgresql.conf and want to measure
its effect on READ. In essence I want to know if the SELECT queries I am firing
repeatedly is reading from the buffer or going directly to the disk.
I am expecting the first SELECT to go to disk and the subsequent
Samuel Stearns wrote:
> Tom Lane wrote:
>> transaction_timestamp() is exactly the same thing as now().
> I got into trouble using now() before.
Using what? What kind of trouble?
> Transaction_timestamp() is really what I need, I think.
test=# \x
Expanded display is on.
test=# begin;
BE
pg_dump and restore are typically fast. Have you tried other -F
values? c does compression which, in your case, on your servers, might
be slow. You could also try running the dump on the server that is
hosting the source database, copying the file across and loading it on
the target server. Or s
(b) How can I verify that my databases are being vacuumed by autovacuum?
pg_stat_user_tables should have a last_autovac column.
Also, you can see autovacuum related messages like:
DEBUG: autovacuum: processing database "postgres"
DEBUG: autovacuum: processing database "template1"
Hi all
I would like to know the quickest way of dumping and restoring the database in
version 8.3 of PostgreSQL database running in RedHat 5.3.
We are currently using the command below, which seems to be very slow. We are
moving from individual database to centralized database
pg_dump -U ent
19 matches
Mail list logo
