Thread: A tool to extract the problematic points of the postgresl log.
Hi everybody, i'd like to know if my database (settings, indexes, materialized views, etc) is correctly tuned. To do this, i think the best way is to watch the queries actually processed and the time needed. The postgres log is the right way to do this, i think. But well, it's a bit dense. Nothing i can't go through, but would you know a better tool than grep to parse the file and extract the problematic points ? As it might be a common problem, maybe somebody as already written a generic tool to do this ? Thanks in advance, David -- David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source
Yes, someone has. Take a look on http://pgfoundry.org; I'm pretty sure it's there. On Tue, Oct 11, 2005 at 11:59:29AM +0200, David Pradier wrote: > Hi everybody, > > i'd like to know if my database (settings, indexes, materialized views, > etc) is correctly tuned. > To do this, i think the best way is to watch the queries actually > processed and the time needed. > > The postgres log is the right way to do this, i think. > > But well, it's a bit dense. > Nothing i can't go through, but would you know a better tool than grep > to parse the file and extract the problematic points ? > > As it might be a common problem, maybe somebody as already written a > generic tool to do this ? > > Thanks in advance, > David > -- > David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source > > ---------------------------(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 > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
I think i've found the right tool on pgfoundry.org : http://pqa.projects.postgresql.org/example.html Thanks for your advice. Best regards, David On Tue, Oct 11, 2005 at 08:46:26AM -0500, Jim C. Nasby wrote: > Yes, someone has. Take a look on http://pgfoundry.org; I'm pretty sure > it's there. > > On Tue, Oct 11, 2005 at 11:59:29AM +0200, David Pradier wrote: > > Hi everybody, > > > > i'd like to know if my database (settings, indexes, materialized views, > > etc) is correctly tuned. > > To do this, i think the best way is to watch the queries actually > > processed and the time needed. > > > > The postgres log is the right way to do this, i think. > > > > But well, it's a bit dense. > > Nothing i can't go through, but would you know a better tool than grep > > to parse the file and extract the problematic points ? > > > > As it might be a common problem, maybe somebody as already written a > > generic tool to do this ? > > > > Thanks in advance, > > David > > -- > > David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source > > > > ---------------------------(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 > > > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- David Pradier -- Directeur Technique de Clarisys Informatique -- Chef de projet logiciels libres / open-source
http://pqa.projects.postgresql.org/ You need to have ruby installed, though. On 11.10.2005 11:59, David Pradier wrote: > Hi everybody, > > i'd like to know if my database (settings, indexes, materialized views, > etc) is correctly tuned. > To do this, i think the best way is to watch the queries actually > processed and the time needed. > > The postgres log is the right way to do this, i think. > > But well, it's a bit dense. > Nothing i can't go through, but would you know a better tool than grep > to parse the file and extract the problematic points ? > > As it might be a common problem, maybe somebody as already written a > generic tool to do this ? -- Regards, Hannes Dorbath