[GENERAL] On-line / off-line trace of SQL statements presented to the Postgres SQL engine
We are using a three-tier application with J2EE, JBoss, Hibernate and a Postgres database. It would be a nice thing to monitor or trace the actual SQL statements processed by the DB. I do not really need the result set as I can get this - if required - using SQL against the DB through the Pgsql interface. Main thing is to know exactly what the database is presented after a GUI click. Very likely that this is more of a Hibernate question but I assume the same desire has been satisfied in some way by this audience. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] Database activity monitoring
The following is an extract of the output from the DB monitoring tool that was delivered with the Progress DB. Sorry for the formatting but I am hopeful you get an idea of what I am talking about. Counters would be updated every x seconds. Is there something - commercial, non- commercial, does not matter - available for Postgres. This was an invaluable tool for monitoring the system both during development and production support. Naturally the counters would differ from that of the Progress DB. Activity - Sampled at 05/30/107 16:21 for 2739:52:42. EventTotal Per SecEventTotal Per Sec Commits 3 0.0 Undos 0 0.0 Record Updates 2 0.0Record Reads 5281 0.0 Record Creates 1 0.0 Record Deletes 0 0.0 DB Writes 8 0.0DB Reads 160 0.0 BI Writes 4 0.0BI Reads70 0.0 AI Writes 0 0.0 Record Locks27 0.0Record Waits 0 0.0 Checkpoints 0 0.0 Buffers Flushed 0 0.0 Rec Lock Waits0 %BI Buf Waits 0 %AI Buf Waits 0 % Writes by APW50 %Writes by BIW 0 %Writes by AIW 0 % Buffer Hits 98 % DB Size 448 KBI Size2048 KAI Size 0 K FR chain 83 blocks RM chain141 blocks Shared Memory 14176 KSegments 1 2 Servers, 0 Users (0 Local, 0 Remote, 0 Batch),2 Apws RETURN - repeat, U - continue uninterrupted, Q - quit: ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[GENERAL] Full vacuum may reclaim space
Other than the fact that no space may need to be reclaimed is anyone aware of any circumstance - e.g. use of numeric data types - where a full vacuum will simply not reclaim space? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Full vacuum may reclaim space
On May 31, 12:11 am, [EMAIL PROTECTED] (Tom Lane) wrote: > [EMAIL PROTECTED] writes: > > Other than the fact that no space may need to be reclaimed is anyone > > aware of any circumstance - e.g. use of numeric data types - where a > > full vacuum will simply not reclaim space? > > There are several corner cases where the code will abandon shrinking. > What are you concerned about exactly? > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq After a recent training course we have discovered that certain settings may have prevented the full vacuum from doing the job requested. I.e. our configuration was well out of whack. Did want to say thanks to all for the feedback and I will connect again of the problem persists. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
