The audit finished up overnight, but i'll try running a test tonight
so i can get a better idea of what is going on.
On Mar 28, 2007, at 3:44 AM, Richard Huxton wrote:
What's the limiting factor? Disk? CPU?
i'm imagining disk io. its a simple query
Any chance of seeing the queries that are causing the problem?
essentially:
update table_a set is_audited = true where id = :serial_id
update table_a set is_audited = true where id in :serial_ids
yes, just toggling a single flag
How many rows do they affect?
1 per query. i tried doing batch queries from 10-10k -- no difference.
Do you have lots of indexes or foreign-key constraints that might
be taking up time to update/check?
nothing fkeys on the column that is updated.
1 index must be updated by the operation.
Do your logs show messages about checkpointing happening too often?
new server - i forgot to enable logging. fixed, and I'll check tonight.
i have a feeling that might be the reason though - my wal archive was
~ 40gb
On Mar 28, 2007, at 10:18 AM, Tom Lane wrote:
If it's I/O bound, you probably need to increase checkpoint_segments.
i tried playing with # of segments , didn't affect anything. maybe
segment size ?
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
