select * from depesz;

due to requests (in “real life”, not on blog), i put my .vimrc in svn, to be easily accessible.

svn repo at: http://svn.depesz.com/svn/vimrc/

Changes:

1. let analyzer analyze logs from java/hibernate access (executes of prepared (anonymous) plans)
2. ignore “detail:” lines

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

Changes:

1. represent percentage as 99.99, and not 0.99 (better precision, easier to read)
2. treat queries: “select a,b from c” and “select b,a from c” as the same type.

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

another patch from Aleksander ‘A.L.E.C’ Machniak.

Changes:

1. make it possible to sort by avg query runtime
2. round() summary values

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

patch from Aleksander ‘A.L.E.C’ Machniak.

Changes:

1. It’s now possible to return analysis as html table (set $HTML_OUTPUT to 1)
2. It’s now easier to change sorting of generated analysis (set $SORT_ORDER)
3. In html output, all numbers are formatted to %.2f.

Some edits by me, mostly indentation.

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

Changes:

1. skip non-query lines

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

Changes:

1. get connection settings from command line:
   
   ./find.best.tablespace.split.pl “dbi:Pg:dbname=depesz;host=127.0.0.1;port=12345″ depesz
2. calculate only for public schema (can be easily changed)
3. distribute indexes as well - always put indexes on another tablespace than table
4. add comment in generated file about total filesizes in tablespaces *after* migration - so it will be clearer on what to move

svn is located here.

Changes:

1. doesn’t use temp files - does everything in-memory. makes the whole process *way* faster
2. allow setting header information using postgresql log_line_prefix syntax
3. removes dependency on readonly perl module - it is not really common module, and the functionality in this program is very limited
4. allows setting database to track as command line option, or track sqls from all databases

SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk

just recently we got another array for out main production database. this means - we will be able to add new tablespace, thus making everything go faster.

in theory - it’s nice. but which tables to move to the other?

the basic assumption is simple - index on table should not be on the same tablespace as the table itself. that’s easy. but - should we really put all tables on one tablespace, and all indexes on another?

we decided that the important things that should be “boosted” are seeks and writes. sequential reads are (in our situation) more or less irrelevant.

read on to check how we split the load.

- MORE -

svn directory analyze.pgsql.logs has been renamed to pgsql-tools.

it still contains (and will contain) lgo analyzer, but now i will be able to put there more stuff

current url: http://svn.depesz.com/svn/pgsql-tools/trunk.