Re: [PERFORM] investigating slow queries through pg_stat_activity

2005-06-20 Thread George Essig
On 6/20/05, Dan Harris <[EMAIL PROTECTED]> wrote: > Also, I'm sure some people will respond with "turn on query > logging".. I've explored that option and the formatting of the log > file and the fact that EVERY query is logged is not what I'm after > for this project. You don't have to log ever

Re: [PERFORM] investigating slow queries through pg_stat_activity

2005-06-20 Thread Tom Lane
Dan Harris <[EMAIL PROTECTED]> writes: > However, the problem I have is that pg_stat_activity only returns the > first n (255?) characters of the SQL as "current_query", so it gets > chopped off at the end. I would very much like to find out how I can > get the *entire* query that is active.

Re: [PERFORM] investigating slow queries through

2005-06-20 Thread Jacques Caron
Hi, At 19:55 20/06/2005, Dan Harris wrote: Also, I'm sure some people will respond with "turn on query logging".. I've explored that option and the formatting of the log file and the fact that EVERY query is logged is not what I'm after for this project. You can log just those queries that tak

[PERFORM] investigating slow queries through pg_stat_activity

2005-06-20 Thread Dan Harris
I've got some queries generated by my application that will, for some reason, run forever until I kill the pid. Yet, when I run the queries manually to check them out, they usually work fine. To get more information about these queries, I'm writing a utility to take snapshots of pg_stat_a

Re: [PERFORM] autovacuum suggestions for 500,000,000+ row tables?

2005-06-20 Thread Josh Berkus
Alex, > Hi, i'm trying to optimise our autovacuum configuration so that it > vacuums / analyzes some of our larger tables better. It has been set > to the default settings for quite some time. We never delete > anything (well not often, and not much) from the tables, so I am not > so worried abou

Re: [PERFORM] autovacuum suggestions for 500,000,000+ row tables?

2005-06-20 Thread John Arbash Meinel
Alex Stapleton wrote: > > On 20 Jun 2005, at 15:59, Jacques Caron wrote: > ... >> ANALYZE is not a very expensive operation, however VACUUM can >> definitely be a big strain and take a long time on big tables, >> depending on your setup. I've found that partitioning tables (at the >> applica

Re: [PERFORM] autovacuum suggestions for 500,000,000+ row tables?

2005-06-20 Thread Alex Stapleton
On 20 Jun 2005, at 15:59, Jacques Caron wrote: Hi, At 16:44 20/06/2005, Alex Stapleton wrote: We never delete anything (well not often, and not much) from the tables, so I am not so worried about the VACUUM status DELETEs are not the only reason you might need to VACUUM. UPDATEs are im

Re: [PERFORM] autovacuum suggestions for 500,000,000+ row

2005-06-20 Thread Jacques Caron
Hi, At 16:44 20/06/2005, Alex Stapleton wrote: We never delete anything (well not often, and not much) from the tables, so I am not so worried about the VACUUM status DELETEs are not the only reason you might need to VACUUM. UPDATEs are important as well, if not more. Tables that are constan

[PERFORM] autovacuum suggestions for 500,000,000+ row tables?

2005-06-20 Thread Alex Stapleton
Hi, i'm trying to optimise our autovacuum configuration so that it vacuums / analyzes some of our larger tables better. It has been set to the default settings for quite some time. We never delete anything (well not often, and not much) from the tables, so I am not so worried about the VAC

Re: [PERFORM] How to determine whether to VACUUM or CLUSTER

2005-06-20 Thread Jim C. Nasby
On Wed, Jun 15, 2005 at 11:34:18AM -0400, Ken Shaw wrote: > Hi All, > > I have an app that updates a PostgreSQL db in a batch fashion. After > each batch (or several batches), it issues VACUUM and ANALYZE calls on > the updated tables. Now I want to cluster some tables for better > performance.