Analyze tool?
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it will
recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?
Regards,
BTJ
--
-----------------------------------------------------------------------------------------------
Bjørn T Johansen
btj@havleik.no
-----------------------------------------------------------------------------------------------
Someone wrote:
"I understand that if you play a Windows CD backwards you hear strange Satanic messages"
To which someone replied:
"It's even worse than that; play it forwards and it installs Windows"
-----------------------------------------------------------------------------------------------
2010/10/1 Bjørn T Johansen <btj@havleik.no>:
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it will
recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?
You can set log_min_duration_statement to log statements which take
over a certain amount of time, and then use pgFouine to read the log
files and identify the most frequently run queries, and the longest
queries.
You can also use the auto_explain contrib module
(http://www.postgresql.org/docs/9.0/static/auto-explain.html) to log
the plans of queries which take too long. However, I don't think
pgFouine can use those outputs.. at least not yet.
But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.
There might be a tool out there for PostgreSQL like you describe,
although I'm not personally aware of it.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 01/10/2010 11:53, Bj�rn T Johansen a �crit :
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it will
recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?
There some work about this kind of feature but nothing officially
released AFAIK.
See http://www.pgcon.org/2010/schedule/events/233.en.html
Regards,
BTJ
- --
Jehan-Guillaume (ioguix) de Rorthais
www.dalibo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkylvzcACgkQxWGfaAgowiIDKgCfXCvYxRC5Dmpbj/VAXmBJ8JxM
wb8Aniq3Aho1WlMZbOA0/sdaWEcSHGcg
=dS1n
-----END PGP SIGNATURE-----
On Fri, 1 Oct 2010 11:30:59 +0100
Thom Brown <thom@linux.com> wrote:
2010/10/1 Bjørn T Johansen <btj@havleik.no>:
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it
will recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?You can set log_min_duration_statement to log statements which take
over a certain amount of time, and then use pgFouine to read the log
files and identify the most frequently run queries, and the longest
queries.
Sounds like a something that should be tried...
You can also use the auto_explain contrib module
(http://www.postgresql.org/docs/9.0/static/auto-explain.html) to log
the plans of queries which take too long. However, I don't think
pgFouine can use those outputs.. at least not yet.
Ok, plan B...
But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.
Yes, but it would be nice to be pointed in the right direction first, but it seems like log_min_duration_statement can be used for that...
And also running explain involves manually work, would have been nice with some automatic procedure....
Thx... :)
BTJ
2010/10/1 Bjørn T Johansen <btj@havleik.no>:
On Fri, 1 Oct 2010 11:30:59 +0100
Thom Brown <thom@linux.com> wrote:2010/10/1 Bjørn T Johansen <btj@havleik.no>:
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it
will recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?You can set log_min_duration_statement to log statements which take
over a certain amount of time, and then use pgFouine to read the log
files and identify the most frequently run queries, and the longest
queries.Sounds like a something that should be tried...
You can also use the auto_explain contrib module
(http://www.postgresql.org/docs/9.0/static/auto-explain.html) to log
the plans of queries which take too long. However, I don't think
pgFouine can use those outputs.. at least not yet.Ok, plan B...
But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.Yes, but it would be nice to be pointed in the right direction first, but it seems like log_min_duration_statement can be used for that...
And also running explain involves manually work, would have been nice with some automatic procedure....
I agree. I believe MSSQL has a similar tool too, so surprised a 3rd
party hasn't already come up with one.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
Then to get all statements would one simply set log_min_duration to some
arbitrarily small value?
Show quoted text
On 10/01/2010 04:30 AM, Thom Brown wrote:
2010/10/1 Bj�rn T Johansen <btj@havleik.no>:
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it will
recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?You can set log_min_duration_statement to log statements which take
over a certain amount of time, and then use pgFouine to read the log
files and identify the most frequently run queries, and the longest
queries.You can also use the auto_explain contrib module
(http://www.postgresql.org/docs/9.0/static/auto-explain.html) to log
the plans of queries which take too long. However, I don't think
pgFouine can use those outputs.. at least not yet.But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.There might be a tool out there for PostgreSQL like you describe,
although I'm not personally aware of it.
On 1 October 2010 14:43, Rob Sargent <robjsargent@gmail.com> wrote:
Then to get all statements would one simply set log_min_duration to some
arbitrarily small value?
Well, 0 will do, although if you're got a busy cluster, this'll slow
it down. Its default is -1 which means disabled.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
Rob Sargent skrev 2010-10-01 15.43:
Then to get all statements would one simply set log_min_duration to some
arbitrarily small value?
From default postgresql.conf comments:
-1 is disabled, 0 logs all statements and their durations, > 0 logs only
statements running at least this number of milliseconds
Also see 18.7.2 in docs:
http://www.postgresql.org/docs/current/interactive/runtime-config-logging.html
Regards
/roppert
Show quoted text
On 10/01/2010 04:30 AM, Thom Brown wrote:
2010/10/1 Bjørn T Johansen<btj@havleik.no>:
We are using both DB2 and PostgreSQL at work and DB2 has a nice tool, i5 Navigator, where one can enable logging of SQL statements and then it will
recommed indexes that should/could be created to increase speed...
Does there exist a similar tool for PostgreSQL?You can set log_min_duration_statement to log statements which take
over a certain amount of time, and then use pgFouine to read the log
files and identify the most frequently run queries, and the longest
queries.You can also use the auto_explain contrib module
(http://www.postgresql.org/docs/9.0/static/auto-explain.html) to log
the plans of queries which take too long. However, I don't think
pgFouine can use those outputs.. at least not yet.But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.There might be a tool out there for PostgreSQL like you describe,
although I'm not personally aware of it.
2010/10/1 Thom Brown <thom@linux.com>:
But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.
A couple related tools to help with explain plans are the query
analyzer in pgAdmin
(http://www.pgadmin.org/images/screenshots/pgadmin3_macosx.png), and
online at http://explain.depesz.com/
2010/10/1 bricklen <bricklen@gmail.com>:
2010/10/1 Thom Brown <thom@linux.com>:
But to find out what indexes you'll need, getting used to reading
query plans will help as it will show you more than just where
sequentials scans are taking place. It will also show you what the
planner believes a query will cost compared to how much it actually
costs, which can provide insight into tables which require vacuuming,
indexes which might need clustering, or table stats which require
modifying to match you data.A couple related tools to help with explain plans are the query
analyzer in pgAdmin
(http://www.pgadmin.org/images/screenshots/pgadmin3_macosx.png), and
online at http://explain.depesz.com/
Believe it or not, I still prefer to read the plain text query plan,
although pgAdmin's graphical representation is quite nice.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935