A majority of the time I just want to see the tables. When using pgAdmin3, I am forced to expand Servers->Local Server->Databases-><the desired database>->Schema->Public->Tables
And then when I finally get to the table I want, if I double click it, it brings up the properties for the table? Huh?
So I figure out I must click the table icon on the toolbar to bring up the table. Instead of bringing up the data within the same pane, it pops up a second window? Grrr....
While the tool gets the job done, I'm starting to miss MySQL just for the sake of having CocoaMySQL at my side.
Yes, that is annoying, but at least the 1.8.1 version of pgAdmin opens in the last db/schema used... that is the behavior I get.
> So I figure out I must click the table icon on the toolbar to bring up the table. Instead of bringing up the data within the same pane, it pops up a second window? Grrr....
File -> Options -> Preferences. Unmark "Show object properties on doubleclick in treeview?" Does that help?
I use a combination of tools:
Aqua Data Studio
PgMaestro via Parallels
POSTGRES AT HI5, Paul Lindner / Ram Gudavalli, June 12th, 2007
Harvard's Leadership for a Networked World uses PG - http://lnwprogram.org
DIYPlanner.com uses Drupal/PG - http://diyplanner.com
PowerfulIntentions.com (lots of forums, separate user pages, etc. all dynamically generated from PG database) - http://www.powerfulintentions.com
But when I look at the XML functions [2], I can start to see where the real value is. In Chron X, we're storing vast sums of XML in SQL as strings, so being able to parse it per-element and pull them could be very helpful.
[1]http://www.postgresql.org/docs/8.3/static/datatype-xml.html
[2]http://www.postgresql.org/docs/8.3/static/functions-xml.html
Here's an example taken from Nikolay Samokhvalov's XML Support in PostgreSQL paper[1].
CREATE INDEX i_table1_xdata ON table1
USING btree( xpath_array(xdata, '//person/@name') );
[1] - http://www.pgcon.org/2007/schedule/attachments/16-xml_in_pos...http://enfranchisedmind.com/blog/2006/11/04/postgres-for-the...
Any comments?
If you have a query with a predicate that can be pushed down to a subtable index then you're probably ok. However if you are doing something more intensive like an unqualified aggregation then you'll be in for a disappointment since the executor doesn't know how to preserve ordering when it scans the subtables. It will always give you a hash join or a merge join involving an intermediate sort even when the sort could be avoided by using an index scan of the subtables with something like a priority queue.
This can be worked around by doing your own incremental aggregations over the subtables and combining them, but it's a little bit of a pain.
http://images.omniti.net/omniti.com/talks/partitions-public....