PostgreSQL 9.3 beta: Federated databases and more
lwn.net
lwn.net
>>Of course, if you're in the southern hemisphere, it's not spring for you. Nor if you live in the north Midwest of the US or central Canada. Sorry about that; we just track the weather with PostgreSQL, we don't control it.
I live in the north Midwest (Wisconsin) and it is currently 72F (should hit 80 today) and sunny, with birds chirping outside- I'm pretty sure it is spring- which started Wednesday, March 20 regardless of it being cold as hell here at the time.
I think some native Californians have trouble with the idea it can be under -15F in February and over 100F in August in some places.
We have weird weather but May is definitely spring, I think the coastal people have a weird perception of what the midwest/north is actually like. Once May starts we're basically a few weeks from god awful summer heat like anywhere else.
Yeah, it snowed here for a moment on Saturday, but Tuesday it hit 89F. :)
>>Once May starts we're basically a few weeks from god awful summer heat like anywhere else.
With exceptions of course, like last year where the snow was gone by mid March and I went camping on St. Patties day- in shorts and a T-shirt... :) and was bit my mosquitoes :(
FDW extends that idea to arbitrary data stores. Wrappers exist for Oracle, MySQL, Redis, Amazon S3, text files, etc.
* With FDWs, you can push down predicates to the remote end. So, if you do: "SELECT * FROM myRemoteTable WHERE id = 2345", then it can just use the index on the remote side rather than pulling all the data to the local side and filtering.
* You can (as of 9.3) insert, update, and delete on the local side and it will pass through to the remote side.
Here is a discussion and answer in Stack overflow: http://stackoverflow.com/a/1109198/1646663
I meant to say constraint exclusion. Exclusion constraints would be pretty hard to implement in a distributed system.
That said - constraint exclusion wouldn't be all that rough, would it? The eventual goal I am thinking of is more effective query plans for UNION views over a bunch of federated partitions.
It would be cool, though ;-)
"constraint exclusion wouldn't be all that rough, would it"
There are two interpretations of that:
* Passing a predicate down to the remote side so that the remote server can use it to exclude partitions. I believe this already works.
* Using CHECK constraints on the local side so that foreign tables can be excluded on the local side. This is a little trickier because it's hard to know that there are really no tuples on the remote side that violate the constraint. It's debatable how important that is, but it does need to be handled sanely somehow if the situation arises.