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/environment/.vim/main-rc.vim
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/environment/.vim/main-rc.vim
Changes:
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
Changes:
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
another patch from Aleksander ‘A.L.E.C' Machniak.
Changes:
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
patch from Aleksander ‘A.L.E.C' Machniak.
Changes:
Some edits by me, mostly indentation.
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
Changes:
svn is located here.
Changes:
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.
Continue reading finding optimum tables placement in 2-tablespace situation
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.