Nothing special about that table. One index.
It really seems that the system would grind to a stand-still when a lot
of non-transaction inserts were run combined with the creation of some
large temp tables.
Since we added transactions and started using truncate, things have
cleared up nicely. The suggestions here really helped.
Does anyone know of some established postgresql consultants that can be
hired for emergency analysis/tuning when things come up?
Rusty
Alan Hodgson wrote:
On Monday 12 January 2009, Bill Preston <billpreston@xxxxxxxxxxxxxxxx>
wrote:
As to the second example with the delete. There are no foreign keys.
For the index. If the table has fields a,b,c and d.
We have a btree index (a,b,c,d)
and we are saying DELETE FROM table_messed_up WHERE a=x.
Is there anything special about this table? Does it have like a hundred
indexes on it or something? Because deleting 8k rows from a normal table
should never take more than a couple of seconds.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
