Peter Bauer wrote:
Hi all,
for further investigation we seperated the sub-SELECT from the DELETE
statement and it looks like the SELECT is usually finished in some 100
milliseconds but after some minutes it suddenly takes some minutes.
Explain analyzes before and after should give some insight
> All other loadtests (no locking or no indexing) ended up in very high
> load and an unusable system after max. one hour because of the very
> long running sub-SELECT of the DELETE statement.
>
> So i think that sometimes there were deadlocks between these 3
> statements which were detected and
Hi all,
here comes an update: Currently a loadtest is running since 4 hours
which did not cause any problems so far. There are about 20 rows
inserted, updated and deleted per hour.
We made column_indexes for location1, location2, location3, register,
type and multi_column_index for isbackup,
Hi,
we had these problems with Version 7.4.7, you can find the old thread here:
http://archives.postgresql.org/pgsql-general/2006-09/msg00079.php
br,
Peter
2006/10/21, Chris Mair <[EMAIL PROTECTED]>:
> its just a vacuumdb --all. We already learned that full vacuums are
> evil because the data
> its just a vacuumdb --all. We already learned that full vacuums are
> evil because the database was carrupted after some time.
Wait a sec...
vacuum full maybe evil in the 'locks stuff and takes long to run'-sense,
but it should definitly NOT corrupt your database.
Are you sure there's no issue
"Peter Bauer" <[EMAIL PROTECTED]> writes:
> we have a theory for the root of all evil which causes a reproducable
> deadlock which is not detected by Postgre:
> The DELETE statement contains a select which waits for a sharelock
> (according to pg_locks and pg_stat_activity) on rows locked by the
>
Hi all,
we have a theory for the root of all evil which causes a reproducable
deadlock which is not detected by Postgre:
The DELETE statement contains a select which waits for a sharelock
(according to pg_locks and pg_stat_activity) on rows locked by the
UPDATE statement. The UPDATE itself waits
Hi all,
for further investigation we seperated the sub-SELECT from the DELETE
statement and it looks like the SELECT is usually finished in some 100
milliseconds but after some minutes it suddenly takes some minutes.
Peter
2006/10/20, Peter Bauer <[EMAIL PROTECTED]>:
Hi all,
we have a theory
thank you very much, we will test it
br,
Peter
2006/10/19, Jim C. Nasby <[EMAIL PROTECTED]>:
On Thu, Oct 19, 2006 at 01:57:56PM +0200, Peter Bauer wrote:
In the update statement, don't wrap the ID values in quotes. At best
it's extra work; at worse it will fool the planner into not using the
in
On Thu, Oct 19, 2006 at 01:57:56PM +0200, Peter Bauer wrote:
In the update statement, don't wrap the ID values in quotes. At best
it's extra work; at worse it will fool the planner into not using the
index.
> shared_buffers = 1000 # min 16 or max_connections*2, 8KB each
This is *way* to
thank you, so we will perform the tests with such a vacuum configuration,
br,
Peter
2006/10/19, Tom Lane <[EMAIL PROTECTED]>:
"Peter Bauer" <[EMAIL PROTECTED]> writes:
> There is a table called tableregistrations where per day about
> 1 million rows are INSERTed
> 2 SELECTs should be perfor
Hi,
the drbd device can only be active and mounted on one machine, so the
other is just in standby.
Regards,
Peter
2006/10/19, Richard Huxton :
Peter Bauer wrote:
> - Two of these clusters are using the same PostgreSQL installation to
> share the data
Just checking - you're not sharing the sa
Peter Bauer wrote:
- Two of these clusters are using the same PostgreSQL installation to
share the data
Just checking - you're not sharing the same data files between two
machines here, are you? Because that's not good.
--
Richard Huxton
Archonet Ltd
---(end of b
"Peter Bauer" <[EMAIL PROTECTED]> writes:
> There is a table called tableregistrations where per day about
> 1 million rows are INSERTed
> 2 SELECTs should be performed on it
> 1 UPDATEs should be performed where about 100 rows are updated
> with each execution
> 1 DELETEs should be per
Hi,
its just a vacuumdb --all. We already learned that full vacuums are
evil because the database was carrupted after some time.
Regards,
Peter
2006/10/19, Tomasz Ostrowski <[EMAIL PROTECTED]>:
On Thu, 19 Oct 2006, Peter Bauer wrote:
> A vaccum of the whole database is performed every 10 minu
On Thu, 19 Oct 2006, Peter Bauer wrote:
> A vaccum of the whole database is performed every 10 minutes with
> cron
What is the command you use? Maybe you are vaccuming with "-f" and
locking the whole table.
Regards
Tometzky
--
...although Eating Honey was a very good thing to do, there was a
mo
Hi all,
we are struggling for some time now with PostgreSQL 8.1.4 and the
situation is pretty critical so please help with whatever comes to
your mind.
We even did an upgrade from version 7.4.13, tried different vacuum
configurations and optimized the configuration.
There is a table called table
17 matches
Mail list logo
