Re: [PERFORM] duration logging setting in 7.4

Ryszard Lach wrote: > > Hi. > > I'm trying to set run-time environment in pgsql7.4 so, that it prints > all statements with duration time, but I can't understand why setting > log_min_duration_statement to '0' causes printing to syslog plenty of > lines ending with 'duration: statement:', i.e. wi

[PERFORM] duration logging setting in 7.4

Hi. I'm trying to set run-time environment in pgsql7.4 so, that it prints all statements with duration time, but I can't understand why setting log_min_duration_statement to '0' causes printing to syslog plenty of lines ending with 'duration: statement:', i.e. without any statement string (except

Re: [PERFORM] Top n queries and GROUP BY

Rich Cullingford wrote: All, This is a straight SQL question, maybe not appropriate for a performance list, but... I have a simple stock holdings setup: => select * from t1; nam |co | num -+---+-- joe | ibm | 600 abe | ibm | 1500 joe | cisco | 1200 a

[PERFORM] Top n queries and GROUP BY

All, This is a straight SQL question, maybe not appropriate for a performance list, but... I have a simple stock holdings setup: => select * from t1; nam |co | num -+---+-- joe | ibm | 600 abe | ibm | 1500 joe | cisco | 1200 abe | cisco | 800 j

[PERFORM] Backup/restore of pg_statistics

Hi, I understand that it is not possible to occasionally re-plan the queries in a PL/pgSQL function without dropping and re-creating the function. I think it would be useful if the queries in a PL/pgSQL function could be re-planned on-the-fly. When a lot of data has been added/modified and ANALY

Re: [PERFORM] INSERT extremely slow with large data sets (fwd)

On Sat, Nov 15, 2003 at 05:13:38AM -0800, George Essig wrote: > > VACUUM ANALYZE will reclaim disk space and update statistics used Strictly speaking, it does not reclaim disk space. It merely marks it as available, assuming you have enough room in your free space map. VACUUM FULL reclaims disk