From: Mischa Sandberg <mischa.sandberg@telus.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Federated PG servers -- Was: Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
Date: Wed, 11 May 2005 14:21:22 -0700
Message-ID: <1115846482.428277525b64f@webmail.telus.net> (raw)
In-Reply-To: <29017.1115777867@sss.pgh.pa.us>
References: <427F6853.90308@cs.concordia.ca>
<427F757A.8000407@samurai.com>
<59d991c405050908271b55e673@mail.gmail.com>
<427F8321.5030702@samurai.com>
<20050509163423.GH35026@decibel.org>
<427F9211.2090008@samurai.com>
<20050509165133.GJ35026@decibel.org>
<427FFCD3.1010803@samurai.com>
<4407.1115698257@sss.pgh.pa.us>
<428037A2.4060304@samurai.com>
<6686.1115700888@sss.pgh.pa.us>
<878y2nsj7i.fsf@stark.xeocode.com>
<9871.1115733198@sss.pgh.pa.us>
<87wtq7q8zk.fsf@stark.xeocode.com>
<25690.1115754605@sss.pgh.pa.us>
<87ll6mr5y8.fsf@stark.xeocode.com>
<29017.1115777867@sss.pgh.pa.us>
Was curious why you pointed out SQL-MED as a SQL-standard approach to
federated servers. Always thought of it as covering access to non-SQL
data, the way the lo_* interface works; as opposed to meshing compatible
(to say nothing of identical) SQL servers. Just checked Jim Melton's
last word on that, to make sure, too. Is there something beyond that,
that I'm missing?
The approach that made first best sense to me (perhaps from having gone
there before) is to leave the SQL syntactically unchanged, and to manage
federated relations via pg_ tables and probably procedures. MSSQL and
Sybase went that route. It won't preclude moving to a system embedded in
the SQL language.
The hurdles for federated SQL service are:
- basic syntax (how to refer to a remote object)
- connection management and delegated security
- timeouts and temporary connection failures
- efficient distributed queries with >1 remote table
- distributed transactions
- interserver integrity constraints
Sometimes the lines get weird because of opportunistic implementations.
For example, for the longest time, MSSQL supported server.db.user.object
references WITHIN STORED PROCEDURES, since the proc engine could hide
some primitive connection management.
PG struck me as such a natural for cross-server queries, because
it keeps everything out in the open, including statistics.
PG is also well set-up to handle heterogeneous table types,
and has functions that return rowsets. Nothing needs to be bent out of
shape syntactically, or in the cross-server interface, to get over the
hurdles above.
The fact that queries hence transactions can't span multiple databases
tells me, PG has a way to go before it can handle dependency on a
distributed transaction monitor.
My 2c.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mischa.sandberg@telus.net, tgl@sss.pgh.pa.us
Subject: Re: Federated PG servers -- Was: Re: [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL
In-Reply-To: <1115846482.428277525b64f@webmail.telus.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox