Re: [PERFORM] Need advice about triggers
Mindaugas Riauba kirjutas K, 10.09.2003 kell 13:21: router_db=# explain analyze update ifdata set ifspeed=256000, ifreason='12121', iflastupdate=CURRENT_TIMESTAMP WHERE clientid='#0003904#'; QUERY PLAN Index Scan using ifdata_clientid_key on ifdata (cost=0.00..5.64 rows=1 width=116) (actual time=0.17..0.36 rows=1 loops=1) Index Cond: (clientid = '#0003904#'::character varying) Total runtime: 1.70 msec (3 rows) could you try the same query on similar table, where clientid is int4 ? is it faster ? does the performance degrade at a slower rate? --- Hannu ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Need advice about triggers
On Tuesday 09 September 2003 13:40, Mindaugas Riauba wrote: Hello, I have small table (up to 1 rows) and every row will be updated once per minute. Table also has before update on each row trigger written in plpgsql. But trigger 99.99% of the time will do nothing to the database. It will just compare old and new values in the row and those values almost always will be identical. Now I tried simple test and was able to do 1 updates on 1000 rows table in ~30s. That's practically enough but I'd like to have more room to slow down. Also best result I achieved by doing commit+vacuum every ~500 updates. How can I improve performance and will version 7.4 bring something valuable for my task? Rewrite to some other scripting language is not a problem. Trigger is simple enough. Well, try it without the trigger. If performance improves markedly, it might be worth rewriting in C. If not, you're probably saturating the disk I/O - using iostat/vmstat will let you see what's happening. If it is your disks, you might see if moving the WAL onto a separate drive would help, or check the archives for plenty of discussion about raid setups. Postgres v7.3.4, shared_buffers=4096 max_fsm settings also bumped up 10 times. Well effective_cache_size is useful for reads, but won't help with writing. You might want to look at wal_buffers and see if increasing that helps, but I couldn't say for sure. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PERFORM] Need advice about triggers
How can I improve performance and will version 7.4 bring something valuable for my task? Rewrite to some other scripting language is not a problem. Trigger is simple enough. Your best bet is to have additional clients connected to the database requesting work. Approx NUMCPUs * 2 + 1 seems to be ideal. (+1 to ensure there is something waiting when the others complete. *2 to ensure that you can have 50% reading from disk, 50% doing calculations) You may simply want to put vacuum into a loop of it's own so it executes ~1 second after the previous run finished. Work should still be going on even though vacuum is running. signature.asc Description: This is a digitally signed message part
Re: [PERFORM] Need advice about triggers
How can I improve performance and will version 7.4 bring something valuable for my task? Rewrite to some other scripting language is not a problem. Trigger is simple enough. Well, try it without the trigger. If performance improves markedly, it might be worth rewriting in C. Nope. Execution time is practically the same without trigger. If not, you're probably saturating the disk I/O - using iostat/vmstat will let you see what's happening. If it is your disks, you might see if moving the WAL onto a separate drive would help, or check the archives for plenty of discussion about raid setups. Bottleneck in this case is CPU. postmaster process uses almost 100% of CPU. Postgres v7.3.4, shared_buffers=4096 max_fsm settings also bumped up 10 times. Well effective_cache_size is useful for reads, but won't help with writing. You might want to look at wal_buffers and see if increasing that helps, but I couldn't say for sure. Disk I/O should not be a problem in this case. vmstat shows ~300kb/s write activity. Mindaugas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
