I just updated explain.depesz.com with bugfix, which changes the way Bitmap Index Scan and Bitmap Heap Scan are displayed. Apparently index and table names were not shown previously.
Thanks go to Viktor Rosenfeld for spotting and reporting the bug.
I just updated explain.depesz.com with bugfix, which changes the way Bitmap Index Scan and Bitmap Heap Scan are displayed. Apparently index and table names were not shown previously.
Thanks go to Viktor Rosenfeld for spotting and reporting the bug.
Let's say you imported some data, but it contains duplicates. You will have to handle them in some way, but to make sensible choice on how to handle it, you need more information.
So, let's start. We have table:
# \d users Table "public.users" Column | Type | Modifiers ------------+--------------------------+---------------------------------------------------- id | integer | not null default nextval('users_id_seq'::regclass) username | text | registered | timestamp with time zone | Indexes: "users_pkey" PRIMARY KEY, btree (id)
Continue reading Tips N’ Tricks – Generating readable reports with plain SQL
I just updated explain.depesz.com with 2 new interface features:
Both features are directed towards people who analyze longer plans – ability to hide parts or just visually see what the Nested Loop is calling in 2nd stage greatly helps me see the flow of query – you can test it, for example, here.
By the way – BIG THANK YOU for Metys for help on it (well, actually, for doing it).
I just modified the internals of explain.depesz.com. Now, it finally stores the plans in database (previously it stored the plans as files in dedicated directory).
Effect for enduser is just that history page should load faster.
But, having the data in database makes it possible to add more features.
One such feature is already added – ability to explain plan, but not list it on history page.
Right now, when you add new plan, you can specify if you want it to be listed with other previous explains – default value is “yes". But if you don't want just anybody to be able to click his way to your plan – there is option for it.
For obvious reasons all previous plans are marked as public now. If you want it to be changed, please contact me – we can probably do something about it.
And as last thing: I would like to express my big THANK YOU to all of you who use explain.depesz.com.
(side note: Catalyst is really cool)
I just updated explain.depesz.com with the newest explain-parsing library version (Pg::Explain v 0.09).
This version will hit CPAN mirrors in next couple of hours.
Changes:
Changes:
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
For quite some time I've been posting about new features in 8.4. First post was over a year ago, on 16th of February 2008.
Now, we just (yesterday) got nice surprise: beta is here:
(depesz@[LOCAL]:5840) 12:39:15 [depesz] # SELECT version(); version ----------------------------------------------------------------------------------------------------------- PostgreSQL 8.4beta1 ON i686-pc-linux-gnu, compiled BY GCC gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3), 32-bit (1 ROW)
Since I don't expect any new features in beta and release candidate stages, let me put some short summary.
Some years ago I learned of existence of (supposedly cool) POE framework for Perl. I tried to use it for some projects, but the learning curve proved to be fatal for my interest.
All the time I felt that POE is great, it's just that I'm too stupid to be able to actively use it.
Time passed by. Something like half a year ago, friend asked me if it would be possible for me to write a cool program – HTTP proxy for their MUD.
Changes:
SVN repo at: http://svn.depesz.com/svn/pgsql-tools/trunk
So, you have a table which looks like this:
# \d test Table "public.test" Column | Type | Modifiers -----------+---------+--------------------------------------------------- id | integer | not null default nextval('test_id_seq'::regclass) parent_id | integer | x | text | Indexes: "test_pkey" PRIMARY KEY, btree (id) Foreign-key constraints: "test_parent_id_fkey" FOREIGN KEY (parent_id) REFERENCES test(id) Referenced by: "test_parent_id_fkey" IN test FOREIGN KEY (parent_id) REFERENCES test(id)
And you would like to easily get all children starting from given node?
Continue reading Getting list of all children in “adjacency list" tree structure