Re: [GENERAL] Strange slow database

loat. We vacuum pg_attribute (and every other table with an entry in pg_tables) every ten minutes. What other that temp tables could bloat pg_attribute? We use refcursors to return data from our stored procedures. We also have a few stored procedures that return SETOF. Thanks for helping us out on

Re: [GENERAL] Strange slow database

sed 0.72 sec. 18/11/2005 03:02:30 VACUUM This is from our vacuum process log. The first index there is the one in question. Hmm, any clues? Of course everything is running at full speed currently. -- David Mitchell Software Engineer Telogis ---(end of broadcast)--

Re: [GENERAL] Strange slow database

r queries appear to have sped up not just on the servers we reindexed, but across the whole cluster - so apparently something else is affecting the speed of this all, not just bloat. We're scratching our heads, this is nothing if not a little frustrating. -- David Mitc

[GENERAL] Strange slow database

3.2Ghz running Linux kernel 2.6.10. Postgres version 8.0.1. Machines have 2Gb ram and two 10k RPM disks in a RAID-0 configuration. Regards -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 9: In versions below 8.0, the plan

Re: [GENERAL] Stopping Postgres

avid Tom Lane wrote: David Mitchell <[EMAIL PROTECTED]> writes: What is the best way to quickly and reliably stop postgres? We've found that pg_ctl doesn't work for us very well, frequently failing to actually stop the postmaster (it times out and reports that it has failed to st

[GENERAL] Stopping Postgres

want to kill -9, obviously. How do other people ensure that postgres is properly stopped in a timely manner? Regards -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Vacuum causing crashes

ux not to overcommit memory. Cheers Doug, that's exactly what it was. That explains a lot of mysterious process deaths recently. Thanks heaps -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 2: you can get off a

[GENERAL] Vacuum causing crashes

9). It appears these crashes occur when we try to stop a vacuum by interrupting the vacuumdb process, but sometimes they occur without us having to do this. Any ideas? We didn't experience so many database crashes before we started vacuuming regularly. Regards -- David Mitchell Softw

Re: [GENERAL] Vacuum advice

ough it has 500 rows, it ended up with about 2million dead tuples, which left a lot to be desired in terms of seq scan speed. Vacuum full cleared this up, so I assume a frequent regular vacuum would keep it in tip top condition. We are using PG 8.0.1. Thanks for your help Tom. -- David Mi

Re: [GENERAL] Vacuum advice

tween). We're thinking we might set up vacuum_cost_limit to around 100 and put vacuum_cost_delay at 100 and then just run vacuumdb in a cron job every 15 minutes or so, does this sound silly? -- David Mitchell Software Engineer Telogis ---(end of broadcast)---

[GENERAL] Vacuum advice

l postgres alter the column in-place? Thanks for your help -- David Mitchell Software Engineer Telogis ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTE

[GENERAL] Index problem

er: (((flags)::integer & 64) = 64) Can somebody please help? -- David Mitchell Software Engineer Telogis NOTICE: This message (including any attachments) contains CONFIDENTIAL INFORMATION intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient,

Re: [GENERAL] BitTorrent tracker

ed ot hit ... On Thu, 10 Mar 2005, David Mitchell wrote: Hi, It would appear the bittorrent tracker is down or broken. I can't download anything from postgresql (but I can from other torrents), and I can't seed either. -- David Mitchell Software Engineer Telogis NOTICE: This message

[GENERAL] BitTorrent tracker

Hi, It would appear the bittorrent tracker is down or broken. I can't download anything from postgresql (but I can from other torrents), and I can't seed either. -- David Mitchell Software Engineer Telogis NOTICE: This message (including any attachments) contains CONFIDENTIAL I