While I have enjoyed Postgres's reliability, the clients (for OSX) have left me feeling empty.
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.
> When using pgAdmin3, I am forced to expand Servers->Local Server->Databases-><the desired database>->Schema->Public->Tables
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?
Looking over the XML datatye [1], at first it doesn't seem that this would be very useful.. It doesn't seem to index the XML, only store it in a string-like manner..
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.
It doesn't index the XML because it also doesn't provide any comparison methods for XML. Largely because string comparisons on XML tend to be less than useful, I think.
Although you can't index xml columns directly, you can define functional indexes over them. As long as you are careful to use the same function in your where clauses the index can be used.
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') );
I'm not familiar with how they've done it in PostgreSQL, but DB2 does support XML indexes. You just have to write an XPath statement to represent what is stored in the index. Then you can write an XQuery statement and the query engine will use that index. It's quite fast.
Unfortunately the current PostgreSQL optimizer/executor doesn't do as much as it could when joining records from subtables partitioned with inherits clauses.
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.
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.